Skip Menu |

This queue is for tickets about the Thread-Serialize CPAN distribution.

Report information
The Basics
Id: 2038
Status: resolved
Priority: 0/
Queue: Thread-Serialize

People
Owner: Nobody in particular
Requestors: ivorw-cpan [...] xemaps.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.05
Fixed in: (no value)



Subject: Thread-Serialize-0.05 fails tests on Win32 (ActiveState 5.8.0)
bash-2.05b$ nmake test Microsoft (R) Program Maintenance Utility Version 1.50 Copyright (c) Microsoft Corp 1988-94. All rights reserved. D:\programs\perl-5.8.0\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', 'blib\arch')" t\Serialize.t t\Serialize....Bareword found where operator expected at (eval 5) line 3, near " #line 92 "D:\ivor\Thread-Serialize-0.05\blib\lib/Thread/Serialize.pm (loaded on demand from offset 2408 for 413 bytes) ub import" (Missing operator before import?) Bareword found where operator expected at (eval 7) line 3, near "#line 92 "D:\ivor\Thread-Serialize-0.05\blib\lib/Thread/Serialize.pm (loaded on demand from offset 2408 for 413 bytes) ub import" (Missing operator before import?) Undefined subroutine &main::freeze called at t\Serialize.t line 18. # Looks like you planned 8 tests but only ran 2. # Looks like your test died just after 2. t\Serialize....dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 3-8 Failed 6/8 tests, 25.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t\Serialize.t 255 65280 8 6 75.00% 3-8 Failed 1/1 test scripts, 0.00% okay. 6/8 subtests failed, 25.00% okay. NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' : return code '0x2' Stop. bash-2.05b$
Date: Thu, 6 Feb 2003 19:53:22 +0100
To: bug-Thread-Serialize [...] rt.cpan.org, "AdminCc of cpan Ticket #2038": ;
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [cpan #2038] Thread-Serialize-0.05 fails tests on Win32 (ActiveState 5.8.0)
RT-Send-Cc:
Looks like the offset in the file is incorrect. Could this be some weird LF -> CRLF interaction with seek()? If I check the offset in my original file, it shows up at line 91, offset 2316. If I add 91 to 2316 I get 2407, the location from which a read would have been good. Maybe the problem is with tell() then? Showing one more than it should, causing it later to fail? Weird. At 12:48 -0500 2/6/03, via RT wrote: Show quoted text
>This message about Thread-Serialize was sent to you by IVORW ><IVORW@cpan.org> via rt.cpan.org > >Full context and any attached attachments can be found at: ><URL: https://rt.cpan.org/Ticket/Display.html?id=2038 > > >bash-2.05b$ nmake test > >Microsoft (R) Program Maintenance Utility Version 1.50 >Copyright (c) Microsoft Corp 1988-94. All rights reserved. > > D:\programs\perl-5.8.0\bin\perl.exe >"-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', >'blib\arch')" t\Serialize.t >t\Serialize....Bareword found where operator expected at (eval 5) >line 3, near " >#line 92 "D:\ivor\Thread-Serialize-0.05\blib\lib/Thread/Serialize.pm >(loaded on demand from offset 2408 for 413 bytes) >ub import" > (Missing operator before import?) >Bareword found where operator expected at (eval 7) line 3, near >"#line 92 >"D:\ivor\Thread-Serialize-0.05\blib\lib/Thread/Serialize.pm (loaded >on demand from offset 2408 for 413 bytes) >ub import" > (Missing operator before import?) >Undefined subroutine &main::freeze called at t\Serialize.t line 18. ># Looks like you planned 8 tests but only ran 2. ># Looks like your test died just after 2. >t\Serialize....dubious > Test returned status 255 (wstat 65280, 0xff00) >DIED. FAILED tests 3-8 > Failed 6/8 tests, 25.00% okay >Failed Test Stat Wstat Total Fail Failed List of Failed >------------------------------------------------------------------------------- >t\Serialize.t 255 65280 8 6 75.00% 3-8 >Failed 1/1 test scripts, 0.00% okay. 6/8 subtests failed, 25.00% okay. >NMAKE : fatal error U1077: 'C:\WINNT\system32\cmd.exe' : return code '0x2' >Stop. >bash-2.05b$
[liz@dijkmat.nl - Thu Feb 6 14:34:43 2003]: Show quoted text
> Looks like the offset in the file is incorrect. Could this be some > weird LF -> CRLF interaction with seek()?
You are correct. The unpacking process I use for CPAN kits makes MS-DOS style CRLF text files. In terms of byte positions, this will be two characters - a CR followed by an LF. I tried converting the file to Unix LF format, and it passed the tests. I will install the file as Unix LF. Show quoted text
> If I check the offset in > my original file, it shows up at line 91, offset 2316. If I add 91 > to 2316 I get 2407, the location from which a read would have been > good. Maybe the problem is with tell() then? Showing one more than > it should, causing it later to fail?
Where are all these magic numbers coming from? I suggest that if the numbers are hardcoded somewhere, you need different values depending on the platform ($^O). Mac also uses 2 bytes as LFCR I believe, and VMS uses a really wierd word aligned byte count thingy as its default (but can use Unix STREAM_LF format or DOS STREAM if asked to).
Date: Fri, 7 Feb 2003 12:30:08 +0100
To: bug-Thread-Serialize [...] rt.cpan.org, "AdminCc of cpan Ticket #2038": ;
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Re: [cpan #2038] Thread-Serialize-0.05 fails tests on Win32 (ActiveState 5.8.0)
RT-Send-Cc:
At 06:04 -0500 2/7/03, via RT wrote: Show quoted text
>This message about Thread-Serialize was sent to you by IVORW ><IVORW@cpan.org> via rt.cpan.org > >Full context and any attached attachments can be found at: ><URL: https://rt.cpan.org/Ticket/Display.html?id=2038 > > >[liz@dijkmat.nl - Thu Feb 6 14:34:43 2003]:
> > Looks like the offset in the file is incorrect. Could this be some > > weird LF -> CRLF interaction with seek()?
>You are correct. The unpacking process I use for CPAN kits makes MS-DOS >style CRLF text files. In terms of byte positions, this will be two >characters - a CR followed by an LF. > >I tried converting the file to Unix LF format, and it passed the tests. >I will install the file as Unix LF.
Ok, good to hear that solved it. However, I think there may be a problem lurking deeper... Show quoted text
>
>> If I check the offset in >> my original file, it shows up at line 91, offset 2316. If I add 91 >> to 2316 I get 2407, the location from which a read would have been >> good. Maybe the problem is with tell() then? Showing one more than
> > it should, causing it later to fail?
>Where are all these magic numbers coming from? I suggest that if the >numbers are hardcoded somewhere, you need different values depending on >the platform ($^O).
The numbers came from the error message and the original file. They are not hardcoded. The source is scanned initially, recording tell() positions. Later, these are used to seek(). For some reason, the tell() position recorded is off by one, so that a later seek() causes the "s" of "sub" to go missing. Show quoted text
>Mac also uses 2 bytes as LFCR I believe, and VMS uses a really wierd >word aligned byte count thingy as its default (but can use Unix >STREAM_LF format or DOS STREAM if asked to).
Well, I hope tell() and seek() are internally consistent, as that is what's causing the problem here, I'm afraid... Liz