On Fri, 30 Sep 2005, Leopold Toetsch via RT wrote:
> Andy Dougherty (via RT) wrote:
>
> > With a a fresh checkout (r9274) I get a number of errors where parrot
> > eventually
> > gobbles up all the memory on the system. Here's the first such one:
> >
> > t/op/gc........................
> > # Failed test (t/op/gc.t at line 279)
>
> > # './parrot --gc-debug
> > "/home/doughera/src/parrot/parrot-andy/t/op/gc_13.pir"' failed with exit
> > code 131
> > # Looks like you failed 1 test of 22.
>
> Strange. The test succeeds on linux/86 and OS/X 10.3 darwin. Running it
> through valgrind on the linux box doesn't show any indication of an error.
>
> t/op/gc_13 is using continuations for backtracking and a few closures.
> Maybe you can compare used features of other failing tests, so that the
> error reason can be narrowed a bit.
After resetting my ulimit so that the tests can run without adversely
impacting other uses of the system, I end up with 267 test failures. I
haven't had time to look for common themes. (This is all on Solaris
8/SPARC).
Failed 26/162 test scripts, 83.95% okay. 267/2734 subtests failed, 90.23% okay.
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/dynclass/gdbmhash.t 13 3328 13 13 100.00% 1-13
t/examples/japh.t 1 256 15 1 6.67% 12
t/library/dumper.t 27 6912 27 27 100.00% 1-27
t/library/getopt_long.t 1 256 1 1 100.00% 1
t/library/md5.t 6 1536 6 6 100.00% 1-6
t/library/parrotlib.t 5 1280 6 5 83.33% 1-4 6
t/library/pcre.t 1 256 1 1 100.00% 1
t/library/pge.t 4 1024 6 4 66.67% 2 4-6
t/library/streams.t 18 4608 20 18 90.00% 1-17 19
t/op/calling.t 1 256 37 1 2.70% 35
t/op/gc.t 1 256 22 1 4.55% 13
t/op/string_cclass.t 2 512 6 2 33.33% 5-6
t/op/trans.t 1 256 19 1 5.26% 13
t/p6rules/anchors.t 26 6656 26 26 100.00% 1-26
t/p6rules/backtrack.t 15 3840 15 15 100.00% 1-15
t/p6rules/builtins.t 41 10496 41 41 100.00% 1-41
t/p6rules/capture.t 38 9728 38 38 100.00% 1-38
t/p6rules/cclass.t 18 4608 18 18 100.00% 1-18
t/p6rules/escape.t 19 4864 19 19 100.00% 1-19
t/p6rules/subrules.t 5 1280 5 5 100.00% 1-5
t/p6rules/ws.t 19 4864 21 19 90.48% 1-15 18-21
t/pmc/delegate.t 1 256 9 1 11.11% 9
t/pmc/fixedpmcarray.t 1 256 13 1 7.69% 10
t/pmc/mmd.t 1 256 30 1 3.33% 27
t/pmc/namespace.t 1 256 15 1 6.67% 12
t/src/hash.t 1 256 10 1 10.00% 6
5 tests and 100 subtests skipped.
So far, I've identified 14 tests that panic with 'Out of mem!'. These all
get a null access internal exception, and then try to exit. During
Parrot_exit, the exit handlers get called. The very first one apparently
tries to do a backtrace, and that backtrace ends up gobbling up all the
memory.
Here are some examples:
# got: 'Null PMC access in clone()
# current instr.: '(null)' pc 199
(/home/doughera/src/parrot/parrot-andy/t/op/gc_13.pir:123)
# called from Sub '(null)' pc 199
(/home/doughera/src/parrot/parrot-andy/t/op/gc_13.pir:123)
# Parrot VM: PANIC: Out of mem!
# Null PMC access in get_string()
# current instr.: 'delegate :: __get_string' pc 50
(/home/doughera/src/parrot/parrot-andy/t/pmc/delegate_9.pir:27)
# called from Sub 'delegate :: __get_string' pc 50
(/home/doughera/src/parrot/parrot-andy/t/pmc/delegate_9.pir:27)
# Parrot VM: PANIC: Out of mem!
# Null PMC access in get_iter()
# current instr.: 'cmp_fun' pc 80
(/home/doughera/src/parrot/parrot-andy/t/pmc/fixedpmcarray_10.pir:27)
# called from Sub 'cmp_fun' pc 80
(/home/doughera/src/parrot/parrot-andy/t/pmc/fixedpmcarray_10.pir:27)
# Parrot VM: PANIC: Out of mem!
# got: 'Null PMC access in set_integer_keyed_int()
# current instr.: 'Digest :: _md5_init' pc 72
(runtime/parrot/library/Digest/MD5.pir:81)
# called from Sub 'Digest :: _md5_init' pc 72
(runtime/parrot/library/Digest/MD5.pir:81)
# Parrot VM: PANIC: Out of mem!
(all the t/library/md5_*.pir tests fail in the same way).
Here's a backtrace from t/op/gc_13.pir
[EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal QUIT (Quit)
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] __sigprocmask(0x0, 0xffbecff0, 0x0, 0x0, 0x0, 0x0), at 0xff0d91f0
[2] _resetsig(0xff0db7f4, 0x0, 0x0, 0x225c98, 0xff0ec000, 0x0), at 0xff0ce56c
[3] _sigon(0x225c98, 0xff0f38a8, 0x3, 0xffbed0c4, 0x225c98, 0x5), at
0xff0cdd0c
[4] _thrp_kill(0x0, 0x1, 0x3, 0xff0ec000, 0x1, 0x1dbd80), at 0xff0d0d4c
[5] raise(0x3, 0x224800, 0x1dbc00, 0x1dbc00, 0x40d320, 0x21f), at 0xff14bce0
[6] mem__internal_allocate_zeroed(0x0, 0x1ccf30, 0x3b, 0x43fc40, 0x226b78,
0x0), at 0x4cdf0
[7] compact_pool(0x225f10, 0x226b78, 0x0, 0xffffffff, 0x226af0, 0xa3670), at
0xa3714
[8] mem_allocate(0x225f10, 0xffbed2ec, 0x226b78, 0x90, 0x100, 0x0), at 0xa35f8
[9] Parrot_allocate_string(0x225f10, 0x3cdb48, 0x80, 0xfffffff8, 0x2100,
0x247838), at 0xa3da4
[10] string_make_empty(0x3cdb48, 0x1, 0x80, 0x247798, 0x225c00, 0x1), at
0x53624
[11] Parrot_sprintf_format(0x225f10, 0x3cdb70, 0xffbef4b0, 0x7c200, 0x0,
0xffbef52c), at 0x7ad94
[12] Parrot_sprintf_c(0x225f10, 0x20ad68, 0x1dc580, 0x0, 0xc7, 0x247ba8), at
0x7a8a8
[13] Parrot_Context_infostr(0x0, 0x4d8c28, 0x263598, 0x4d8c20, 0x40d320,
0x4d5e40), at 0xd658c
[14] PDB_backtrace(0x225f10, 0x40d2f0, 0x4fa5a, 0xff191c14, 0x40, 0x0), at
0x76e28
[15] Parrot_exit(0x2b, 0xff1c3a54, 0xff1bfca8, 0xa, 0x1e12a0, 0x21e400), at
0x7a58c
[16] internal_exception(0x2b, 0x1e12a0, 0x0, 0xb1eb0, 0x52e7c, 0x52e94), at
0xd0f2c
[17] Parrot_Null_clone(0x225f10, 0x263598, 0x38, 0xe, 0x4d5e40, 0x17a920), at
0x17a93c
[18] Parrot_clone_p_p(0x4d5cb4, 0xf, 0x4d5e40, 0x92, 0x4d5e40, 0x84ee0), at
0x84f0c
[19] runops_slow_core(0x4d5cb4, 0x1dc400, 0x0, 0xd6400, 0x0, 0xd2800), at
0xd6674
[20] runops_int(0x225f10, 0x4d5998, 0x226058, 0x1, 0x0, 0x1), at 0xd2688
[21] runops(0x225f10, 0x0, 0x1bc1eb, 0x226058, 0x21e400, 0x247bf0), at 0xd5830
[22] Parrot_runcode(0x225f10, 0x443748, 0x70, 0x8, 0x488200, 0x0), at 0x71d54
[23] Parrot_runcode(0x225f10, 0x1, 0xffbefaf4, 0x0, 0x42ae48, 0x226af0), at
0x71aa4
[24] main(0x21e400, 0x225f10, 0xffbefafc, 0x2248ac, 0x0, 0x0), at 0x4aa84
(dbx) quit
Though it doesn't run out of memory, op/calling_35.pir also dumps core.
Here's its backtrace:
(dbx) run t/op/calling_35.pir
Running: parrot t/op/calling_35.pir
(process id 5567)
Foo ok 1
[EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault
address) in Parrot_free_context at 0x4be10
0x0004be10: Parrot_free_context+0x0030: st %g1, [%o0 - 0x64]
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] Parrot_free_context(0x0, 0x248400, 0x1, 0x42863c, 0x4f, 0x138), at 0x4be10
[2] Parrot_RetContinuation_invoke(0x225f10, 0x2483f0, 0x563ee8, 0x3e99c0,
0x247e90, 0x253c40), at 0x1841e0
[3] Parrot_returncc(0x563ee4, 0x225f10, 0x5198a0, 0x8, 0x5198a0, 0x826b0), at
0x826c8
[4] runops_slow_core(0x563ee4, 0x1dc400, 0x0, 0xd6400, 0x0, 0xd2800), at
0xd6674
[5] runops_int(0x225f10, 0x563df0, 0x226058, 0x1, 0x0, 0x1), at 0xd2688
[6] runops(0x225f10, 0x0, 0x1bc1eb, 0x226058, 0x21e400, 0x4b6d38), at 0xd5830
[7] Parrot_runcode(0x225f10, 0x443748, 0x70, 0x3e99c0, 0x8, 0x253508), at
0x71d54
[8] Parrot_runcode(0x225f10, 0x1, 0xffbefa78, 0x0, 0x42ae48, 0x226af0), at
0x71aa4
[9] main(0x21e400, 0x225f10, 0xffbefa80, 0x2248ac, 0x0, 0x0), at 0x4aa84
(dbx) quit
One common theme I see is that the interpreter arguments to
Parrot_Context_infostr()
and Parrot_free_context() are both null. I don't know why.
I don't know what to make of it all yet, but anyone running tests on
shared systems should probably consider setting a conservative ulimit
value.
--
Andy Dougherty [EMAIL PROTECTED]
