Bug 30052

Summary: poke-3.0 and git both fail poke.pkl/in-{1,2,3}.pk tests: expected offset<int<32>,1>, got offset<int<32>,8>
Product: poke Reporter: Sergei Trofimovich <slyich>
Component: defaultAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED INVALID    
Severity: normal CC: jose.marchesi, poke-devel
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: config.log
poke.log

Description Sergei Trofimovich 2023-01-25 22:37:12 UTC
Created attachment 14627 [details]
config.log

Noticed test failures when tried to package poke-3.0 in nixpkgs. Test suite failed 3 tests:

FAIL: poke.pkl/in-1.pk execution test
FAIL: poke.pkl/in-2.pk execution test
FAIL: poke.pkl/in-3.pk execution test

Logs complain that way:

Setting LD_LIBRARY_PATH to :
Execution timeout is: 300
spawn [open ...]
<stdin>:1: error: invalid operand in expression
<stdin>:1: error: expected offset<int<32>,1>, got offset<int<32>,8>
FAIL: poke.pkl/in-1.pk execution test
PASS: poke.pkl/in-2.pk (test for excess errors)
Setting LD_LIBRARY_PATH to :
Execution timeout is: 300
spawn [open ...]
<stdin>:1: error: invalid operand in expression
<stdin>:1: error: expected int<64>, got uint<8>
FAIL: poke.pkl/in-2.pk execution test
PASS: poke.pkl/in-3.pk (test for excess errors)
Setting LD_LIBRARY_PATH to :
Execution timeout is: 300
spawn [open ...]
<stdin>:1: error: invalid operand in expression
<stdin>:1: error: expected int<64>, got uint<8>
FAIL: poke.pkl/in-3.pk execution test

it's x86_64-pc-linux-gnu machine.

Attached full config.log against current poke.git if it's of any help.
Comment 1 Jose E. Marchesi 2023-01-25 22:45:45 UTC
Hello.

Thanks for the report.

These three tests are marked to xfail, not to fail.  For example, for in-1.pk:

  /* { dg-do run { xfail *-*-* } } */
  
  /* { dg-command {10#B in [2#b,10*8#b,3#b]} } */
  /* { dg-output "1" } */

Could it be that your version of dejagnu is old and doesn't support the `xfail' annotation before the triplet?  What version of dejagnu are you using?
Comment 2 Sergei Trofimovich 2023-01-25 22:53:39 UTC
Created attachment 14628 [details]
poke.log
Comment 3 Sergei Trofimovich 2023-01-25 22:55:31 UTC
(In reply to Jose E. Marchesi from comment #1)
> Hello.
> 
> Thanks for the report.
> 
> These three tests are marked to xfail, not to fail.  For example, for
> in-1.pk:
> 
>   /* { dg-do run { xfail *-*-* } } */
>   
>   /* { dg-command {10#B in [2#b,10*8#b,3#b]} } */
>   /* { dg-output "1" } */
> 
> Could it be that your version of dejagnu is old and doesn't support the
> `xfail' annotation before the triplet?  What version of dejagnu are you
> using?

Good question! I think my dejagnu is up to date:

$ dejagnu --version
dejagnu auxiliary launcher (DejaGnu) 1.6.3

testsuite/poke.log is a bit suspicious:

  Test run by slyfox on Wed Jan 25 22:28:47 2023
  Target is .runtest-wrapped
  Host   is x86_64-pc-linux-gnu

'Target' (if it's used for matching) looks wrong.
Comment 4 Jose E. Marchesi 2023-01-25 22:58:25 UTC
(In reply to Sergei Trofimovich from comment #3)
> (In reply to Jose E. Marchesi from comment #1)
> > Hello.
> > 
> > Thanks for the report.
> > 
> > These three tests are marked to xfail, not to fail.  For example, for
> > in-1.pk:
> > 
> >   /* { dg-do run { xfail *-*-* } } */
> >   
> >   /* { dg-command {10#B in [2#b,10*8#b,3#b]} } */
> >   /* { dg-output "1" } */
> > 
> > Could it be that your version of dejagnu is old and doesn't support the
> > `xfail' annotation before the triplet?  What version of dejagnu are you
> > using?
> 
> Good question! I think my dejagnu is up to date:
> 
> $ dejagnu --version
> dejagnu auxiliary launcher (DejaGnu) 1.6.3
> 
> testsuite/poke.log is a bit suspicious:
> 
>   Test run by slyfox on Wed Jan 25 22:28:47 2023
>   Target is .runtest-wrapped
>   Host   is x86_64-pc-linux-gnu
> 
> 'Target' (if it's used for matching) looks wrong.

The target may explain it.
It certainly doesn't match *-*-*
Comment 5 Sergei Trofimovich 2023-01-25 23:00:16 UTC
I think it's my system's `runtest` effect of being a wrapper:

$ cat /nix/store/14fxfqck2l850fyghapmpsa1dvxlxdj1-dejagnu-1.6.3/bin/runtest
#! /nix/store/pj1hnyxhcsw1krmhnbb9rjvqssbzliw8-bash-5.2-p15/bin/bash -e
...
exec -a "$0" "/nix/store/14fxfqck2l850fyghapmpsa1dvxlxdj1-dejagnu-1.6.3/bin/.runtest-wrapped"  "$@"

I suspect that `exec` breaks `argv`. Let's close as INVALID and I'll reopen if I find some evidence of poke being a suspect in handling that rename.
Comment 6 Sergei Trofimovich 2023-01-26 00:33:10 UTC
(In reply to Sergei Trofimovich from comment #5)
> I think it's my system's `runtest` effect of being a wrapper:
> 
> $ cat /nix/store/14fxfqck2l850fyghapmpsa1dvxlxdj1-dejagnu-1.6.3/bin/runtest
> #! /nix/store/pj1hnyxhcsw1krmhnbb9rjvqssbzliw8-bash-5.2-p15/bin/bash -e
> ...
> exec -a "$0"
> "/nix/store/14fxfqck2l850fyghapmpsa1dvxlxdj1-dejagnu-1.6.3/bin/.runtest-
> wrapped"  "$@"
> 
> I suspect that `exec` breaks `argv`. Let's close as INVALID and I'll reopen
> if I find some evidence of poke being a suspect in handling that rename.

I confirm it was a `nixpkgs` wrapper deficiency. Should be worked around by not using wrapper in https://github.com/NixOS/nixpkgs/pull/212688.

Not sure if it's a bug or feature of bash. Asked at bash upstream in https://lists.gnu.org/archive/html/bug-bash/2023-01/msg00082.html.

Still INVALID. Apologies for the noise!
Comment 7 Jose E. Marchesi 2023-01-26 00:36:22 UTC
(In reply to Sergei Trofimovich from comment #6)
> (In reply to Sergei Trofimovich from comment #5)
> > I think it's my system's `runtest` effect of being a wrapper:
> > 
> > $ cat /nix/store/14fxfqck2l850fyghapmpsa1dvxlxdj1-dejagnu-1.6.3/bin/runtest
> > #! /nix/store/pj1hnyxhcsw1krmhnbb9rjvqssbzliw8-bash-5.2-p15/bin/bash -e
> > ...
> > exec -a "$0"
> > "/nix/store/14fxfqck2l850fyghapmpsa1dvxlxdj1-dejagnu-1.6.3/bin/.runtest-
> > wrapped"  "$@"
> > 
> > I suspect that `exec` breaks `argv`. Let's close as INVALID and I'll reopen
> > if I find some evidence of poke being a suspect in handling that rename.
> 
> I confirm it was a `nixpkgs` wrapper deficiency. Should be worked around by
> not using wrapper in https://github.com/NixOS/nixpkgs/pull/212688.
> 
> Not sure if it's a bug or feature of bash. Asked at bash upstream in
> https://lists.gnu.org/archive/html/bug-bash/2023-01/msg00082.html.
> 
> Still INVALID. Apologies for the noise!

No problem!
Thank you very much for taking the effort to report the issue.
(And for packaging poke! :) )