2010/6/1 Parrot <parrot-tickets@lists.parrot.org>
#1670: t/library/lwp.t fails after parallel build
 Reporter:  doughera  |       Owner:
    Type:  bug       |      Status:  new
 Priority:  normal    |   Milestone:
Component:  none      |     Version:  2.4.0
 Severity:  medium    |    Keywords:
    Lang:            |       Patch:
 Platform:            |
 I am getting the following strange failure with t/library/lwp.t, but only
 if I build with {{{make -j 6}}} (or greater).  The test succeeds if I
 build with {{{make -j 5}}}.

 The failure looks like this:

 ok 1 - new ['LWP';'UserAgent']
 ok 2 - new ['LWP';'Protocol';'file']
 ok 3 - isa ['LWP';'Protocol']
 ok 4 - new ['LWP';'Protocol';'http']
 ok 5 - isa ['LWP';'Protocol']
 ok 6 - new ['HTTP';'Request']
 ok 7 - isa ['HTTP';'Message']
 ok 8 - new ['HTTP';'Response']
 ok 9 - isa ['HTTP';'Message']
 "load_bytecode" no file name
 current instr.: 'parrot;HTTP;Date;time2str' pc 8
 called from Sub 'parrot;LWP;UserAgent;_new_response' pc 1445
 called from Sub 'parrot;LWP;UserAgent;send_request' pc 210
 called from Sub 'parrot;LWP;UserAgent;request' pc 406
 called from Sub 'test_unknown_protocol' pc 273 (t/library/lwp.t:68)
 called from Sub 'main' pc 51 (t/library/lwp.t:27)

 Running the whole thing under strace, the load bytecode is failing because
 it's calling
 fstat(1275397164, 0x7fffffffd1c0)       = -1 EBADF (Bad file descriptor)
 where it looks like that first argument to fstat() may have come from a
 previous call to time().

 I have been able to reproduce this problem on a quad-core x86  and on a
 dual-core amd64.  Both were running Debian Linux "Lenny" (aka "stable").

 I have attached the script I used to reproduce the failures, and a tar
 file showing the different outputs of
 {{{ ./parrot t/library/lwp.t}}}, and
 {{{ strace ./parrot t/library/lwp.t}}}.

 I vaguely suspect that the recent shuffling of some ops out of core means
 that some library wasn't available when it was needed, though why that
 didn't result in a build failure is a mystery to me.

 This particular run was at r47170, though I first noticed this problem
 with r47059, and it could be even older than that.

Ticket URL: <https://trac.parrot.org/parrot/ticket/1670>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
parrot-tickets mailing list

I think it is another opcode mixture (see TT #1663),
because the subroutine time2str() doesn't use the opcode load_bytecode.