[BUG] coroutine_3.pasm trampling memory?

[Nick Glencross]

coroutine_3.pasm seems to have some problems with scratchpads, but I
don't know whether the problem is with parrot or the test.

In line 105 of lexical.c (r10019) there is a buffer being overflowed
because the buffer for base is larger than pad_pmc.

valgrind reports 4 occurrences of this for this test, all roughly:

==15739== Thread 1:
==15739== Invalid write of size 1
==15739== at 0x1B901DE7: memcpy (in
/usr/lib/valgrind/vgpreload_memcheck.so)
==15739== by 0x80929A4: scratchpad_new (lexical.c:105)
==15739== by 0x80ED998: Parrot_new_pad_ic (var.ops:49)
==15739== by 0x81643E5: runops_slow_core (runops_cores.c:153)
==15739== by 0x8160405: runops_int (interpreter.c:754)
==15739== by 0x8162F0A: runops (inter_run.c:81)
==15739== by 0x8163121: runops_args (inter_run.c:180)
==15739== by 0x8163225: Parrot_runops_fromc_args (inter_run.c:274)
==15739== by 0x80C5DFB: Parrot_runcode (embed.c:818)
==15739== by 0x80C5C06: Parrot_runcode (embed.c:749)
==15739== by 0x80850CB: main (main.c:640)
==15739== Address 0x1C7A23CB is 3 bytes after a block of size 8 alloc'd
==15739== at 0x1B8FF8F5: malloc (in
/usr/lib/valgrind/vgpreload_memcheck.so)
==15739== by 0x808690C: mem_sys_allocate (memory.c:43)
==15739== by 0x813E9B5: Parrot_FixedPMCArray_set_integer_native
(fixedpmcarray.pmc:426)
==15739== by 0x809292A: scratchpad_new (lexical.c:102)
==15739== by 0x80ED998: Parrot_new_pad_ic (var.ops:49)
==15739== by 0x81643E5: runops_slow_core (runops_cores.c:153)
==15739== by 0x8160405: runops_int (interpreter.c:754)
==15739== by 0x8162F0A: runops (inter_run.c:81)
==15739== by 0x8163121: runops_args (inter_run.c:180)
==15739== by 0x8163225: Parrot_runops_fromc_args (inter_run.c:274)
==15739== by 0x80C5DFB: Parrot_runcode (embed.c:818)
==15739== by 0x80C5C06: Parrot_runcode (embed.c:749)

/Perhaps/ related to this, HP-UX has problems with its global
destruction, the last steps before dieing being:

...
(gdb)
Parrot_really_destroy (exit_code=0, vinterp=0x4006bce0)
at src/inter_create.c:322
322 interpreter->arena_base->DOD_block_level =
(gdb)
324 Parrot_do_dod_run(interpreter, DOD_finish_FLAG);
(gdb)
Parrot_do_dod_run (interpreter=0x4006bce0, flags=4) at src/dod.c:1269
1269 interpreter->arena_base->do_dod_run(interpreter, flags);
(gdb)

Program received signal SIGSEGV, Segmentation fault.

I think that function pointer interpreter->arena_base->do_dod_run may be
corrupt, but gdb is unable to do a backtrace now. I'll open another call
for this if we can address the first issue and it doesn't fix the second.

Regards,

Nick

[Leopold Toetsch]

Nick Glencross wrote:
> coroutine_3.pasm seems to have some problems with scratchpads, but I
> don't know whether the problem is with parrot or the test.

> ==15739== Thread 1:

> ==15739== Invalid write of size 1

Yep. I have seen the overwrite too with scratchpads. But as scratchpads
will be removed RSN in favor of pdd20, we can just ignore this error.

leo

[Nick Glencross]

What should we do with the call in cases like this? Close it or keep
it open until the functionality is obsoleted? Since I now know that
another solution is on its way, I don't mind either way...

Cheers,

Nick