Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

r8118: MSWin32 Test Results

3 views
Skip to first unread message

Ron Blaschke

unread,
May 18, 2005, 5:54:47 PM5/18/05
to perl6-i...@perl.org
Below are the test results of

Windows XP SP2
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
Activestate Python 2.4.1 Build 245
Activestate Perl 5.8.6 Build 811
ANTLR 2.7.5
ICU 3.2
GDBM 1.8.3
GMP 4.1.4

Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t\dynclass\foo.t 3 768 3 3 100.00% 1-3
t\dynclass\gdbmhash.t 13 3328 13 13 100.00% 1-13
t\dynclass\pybuiltin.t 6 1536 6 6 100.00% 1-6
t\dynclass\pyclass.t 6 1536 6 6 100.00% 1-6
t\dynclass\pycomplex.t 2 512 2 2 100.00% 1-2
t\dynclass\pyfunc.t 4 1024 4 4 100.00% 1-4
t\dynclass\pyint.t 26 6656 26 26 100.00% 1-26
t\op\spawnw.t 5 1280 6 5 83.33% 2-6
t\pmc\bigint.t 1 256 22 1 4.55% 22
t\pmc\threads.t 7 1792 11 7 63.64% 2-5 7-9
t\pmc\timer.t 2 512 8 2 25.00% 3 5
2 tests and 65 subtests skipped.
Failed 11/151 test scripts, 92.72% okay. 75/2480 subtests failed, 96.98% okay.

Leopold Toetsch

unread,
May 19, 2005, 4:57:07 AM5/19/05
to Ron Blaschke, perl6-i...@perl.org
Ron Blaschke <mailin...@rblasch.org> wrote:
> Below are the test results of

> Windows XP SP2
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
> for 80x86
> Activestate Python 2.4.1 Build 245
> Activestate Perl 5.8.6 Build 811

[ all dynclasses - ok linker problem ]

> t\op\spawnw.t 5 1280 6 5 83.33% 2-6

exit status?

> t\pmc\bigint.t 1 256 22 1 4.55% 22

What's up with that one?

> t\pmc\threads.t 7 1792 11 7 63.64% 2-5 7-9
> t\pmc\timer.t 2 512 8 2 25.00% 3 5

ok, TODO

leo

Ron Blaschke

unread,
May 19, 2005, 2:36:23 PM5/19/05
to Leopold Toetsch, perl6-i...@perl.org
Leopold Toetsch wrote:
> Ron Blaschke <mailin...@rblasch.org> wrote:

>> t\op\spawnw.t 5 1280 6 5 83.33% 2-6

> exit status?

Quite likely, yes. I'd gladly provide a patch, if someone would
decide The Right Thing To Do. That is, what should
Parrot_Run_OS_Command return? Something platform specific, as
currently implemented? Something that C<waitpid()> returns? Or
something more struct-ered?

>> t\pmc\bigint.t 1 256 22 1 4.55% 22

> What's up with that one?

Maybe my fault. The program segfaults at C<free(s);> in
C<get_string>. Memory gets allocated by a non-debug version of GMP,
and deallocated by a debug Parrot. I'll check what happens with a
debug GMP...

Ron

Ron Blaschke

unread,
May 19, 2005, 7:59:01 PM5/19/05
to Leopold Toetsch, perl6-i...@perl.org

Alright, here's how far I've got. I currently can't make any sense of
it, maybe I'm getting too tired.

The problem seems to be caused by the C<free(s);> in
F<bigint.pmc/get_string>. Well, not the actual cause, but that's
where we fail.

STRING* get_string() {
char *s = bigint_get_string(INTERP, SELF, 10);
STRING *ps = string_from_cstring(INTERP, s, 0);
free(s);
return ps;
}

Here's the top of the call stack.

ntdll.dll!_DbgBreakPoint@0()
ntdll.dll!_RtlpBreakPointHeap@4() + 0x28
ntdll.dll!_RtlpValidateHeapEntry@12() + 0x113
ntdll.dll!_RtlDebugFreeHeap@12() + 0x97
ntdll.dll!_RtlFreeHeapSlowly@12() + 0x23d19
ntdll.dll!_RtlFreeHeap@12() + 0x16470
msvcr71.dll!7d003179()
parrot.exe!Parrot_BigInt_get_string(...) Line 545 + 0xa C

Out of curiosity, I've removed the C<free>, and tests pass just fine.
C<free> back in again, link against debug GMP - pass.
Link against release GMP again - fail.

Now here's something really funny. Here's the test run that fails.

Parrot>parrot -b --gc-debug t\pmc\bigint_22.pir
Parrot>echo %ERRORLEVEL%
-1073741819

And here's one that passes, from the very same command prompt.

Parrot>parrot -b --gc-debug t\pmc\bigint_22.pir
31415926535897932384626433832795028841971693993751
05820974944592307816406286208998628034825342117067
[snip]
35982534904287554687311595628638823537875937519577
81857780532171226806613001927876611195909216420198
Parrot>echo %ERRORLEVEL%
0

The difference, you ask? Another command prompt, that says
C<perl -e "while (1) {}">. Once the CPU is busy, the expected result
shows up. ;-)

The bigint.t test suite still fails, though, in both cases, with the
same error message.

Parrot>perl t\harness t\pmc\bigint.t
t\pmc\bigint....NOK 22#
got: 'Can't spawn ".\parrot.exe "Parrot\t\pmc\bigint_22.pir"":
Bad file descriptor at lib/Parrot/Test.pm line 230.

Ron


Leopold Toetsch

unread,
May 20, 2005, 2:19:52 AM5/20/05
to Ron Blaschke, perl6-i...@perl.org
Ron Blaschke wrote:
> Ron Blaschke wrote:
>

>>>>t\pmc\bigint.t 1 256 22 1 4.55% 22

> The problem seems to be caused by the C<free(s);> in


> F<bigint.pmc/get_string>. Well, not the actual cause, but that's
> where we fail.

mpz_get_str() returned a string that was very likely allocated by a
different "default allocation function".

This is now changed (rev 8129) by first querying the required string
length and using Parrot's allocation function so that the free should be
ok now.

Thanks for investigating,
leo

Ron Blaschke

unread,
May 20, 2005, 7:59:04 AM5/20/05
to Leopold Toetsch, perl6-i...@perl.org

Thought about that too, but then checked the allocation/deallocation
functions, which are simple wrappers around C<malloc> and C<free>, and
stopped there.

What really bothers me is that the behaviour changed with CPU load.
The expected output is print with high CPU load, but not with low, and
can be reproduced. I have this weird feeling I usually only get with
uninitialzed writes and data race conditions lurking behind my back.

t/pmc/bigint now passes, but with Rev 8133 there are several other
failures (even with a fresh checkout).

Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------

imcc\t\reg\spill.t 1 256 9 1 11.11% 5
imcc\t\syn\objects.t 11 2816 11 11 100.00% 1-11
imcc\t\syn\tail.t 1 256 6 1 16.67% 6


t\dynclass\foo.t 3 768 3 3 100.00% 1-3
t\dynclass\gdbmhash.t 13 3328 13 13 100.00% 1-13
t\dynclass\pybuiltin.t 6 1536 6 6 100.00% 1-6
t\dynclass\pyclass.t 6 1536 6 6 100.00% 1-6
t\dynclass\pycomplex.t 2 512 2 2 100.00% 1-2
t\dynclass\pyfunc.t 4 1024 4 4 100.00% 1-4
t\dynclass\pyint.t 26 6656 26 26 100.00% 1-26

t\library\dumper.t 26 6656 26 26 100.00% 1-26
t\library\getopt_long.t 1 256 1 1 100.00% 1
t\library\pcre.t 255 65280 1 2 200.00% 1
t\library\pge.t 3 768 3 3 100.00% 1-3
t\library\streams.t 20 5120 20 20 100.00% 1-20
t\op\gc.t 4 1024 19 4 21.05% 10-11 14 19


t\op\spawnw.t 5 1280 6 5 83.33% 2-6

t\op\string.t 1 256 155 1 0.65% 140
t\pmc\exception.t 1 256 30 1 3.33% 21
t\pmc\freeze.t 8 2048 26 8 30.77% 17-24
t\pmc\mmd.t 8 2048 25 8 32.00% 9 12-16 23-24
t\pmc\object-meths.t 25 6400 28 25 89.29% 1-15 17-20 22-26 28
t\pmc\objects.t 52 13312 62 52 83.87% 1-4 8-15 17-37 40-44 46-
52 54-56 58 60-62
t\pmc\threads.t 1 256 11 1 9.09% 4
2 tests and 63 subtests skipped.
Failed 24/151 test scripts, 84.11% okay. 229/2483 subtests failed, 90.78% okay.

The error message usually goes like this.

...
# got: 'Can't spawn ".\parrot.exe -b --gc-debug "t\op\gc_10.pasm"":


Bad file descriptor at lib/Parrot/Test.pm line 230.

...

To Be Continued...

Ron


Jerry Gay

unread,
May 20, 2005, 10:42:09 AM5/20/05
to Ron Blaschke, Leopold Toetsch, perl6-i...@perl.org

these have been failing for me since ~r8122. i haven't had time to
investigate further.
~jerry

0 new messages