Hi,
I've compiled Pike with --with-dmalloc --with-dmalloc-malloc-leaks --with-checker --with-rtldebug and when I load Caudium I get the following error when it loads one of the Camas modules:
Loading camas_tags... Post-padding overwritten for block at 0xac7bda0 (size 20)! **Location: 0xac7bda0 Type: unknown Refs: 0 gc generation: 11/11 gc pass: 0/0 *** peep.c:187 (1 times) *** pike_memory.c:570 (1 times) **Cannot describe block of unknown type 247 *******************
Then the pike process exit. The previous modules loads without warning. Can you tell me what this mean ?
Dmalloc has discovered that the postpadding of a block has been overwritten, probably due to a buffer overrun in the code that allocated the block. The two linenumbers you see are positions that have handled it.
To locate bugs of that kind I suggest you run with Valgrind. It'll detect the overwriting directly instead and give you a backtrace showing exactly where it occurs.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-06-06 14:24: Subject: Post-padding overwritten
Hi,
I've compiled Pike with --with-dmalloc --with-dmalloc-malloc-leaks --with-checker --with-rtldebug and when I load Caudium I get the following error when it loads one of the Camas modules:
Loading camas_tags... Post-padding overwritten for block at 0xac7bda0 (size 20)! **Location: 0xac7bda0 Type: unknown Refs: 0 gc generation: 11/11 gc pass: 0/0 *** peep.c:187 (1 times) *** pike_memory.c:570 (1 times) **Cannot describe block of unknown type 247
Then the pike process exit. The previous modules loads without warning. Can you tell me what this mean ?
-- David Gourdelier
/ Brevbäraren
Hello,
Dmalloc has discovered that the postpadding of a block has been overwritten, probably due to a buffer overrun in the code that allocated the block. The two linenumbers you see are positions that have handled it.
I am afraid it's not the only point where there is a problem.
To locate bugs of that kind I suggest you run with Valgrind. It'll detect the overwriting directly instead and give you a backtrace showing exactly where it occurs.
Valgrind fails with the error valgrind: the `impossible' happened: unhandled x86 opcode Basic block ctr is approximately 3150000
So I fail back to mtrace() and mpatrol. I run both when starting Hilfe and exiting immediatly. Both shows there are some leaks.
The output from mtrace can be seen at http://www.iteam.org/~tux/pike.trace.txt and output from mpatrol is at http://www.iteam.org/~tux/pike.trace2.txt
Additionnaly mpatrol shows the following error several times:
MEMCOPY: memcpy (0x082D6390, 0x082D6714, 0 bytes, 0x00) [-|-|-] 0x080E3B5F optimize_program+707 at program_areas.h:20 0x080E54AF end_first_pass+559 at program.c:2516 0x080E5558 debug_end_program+28 at program.c:2572 0x080E9D7F init_program+555 at program.c:6199 0x080C34A5 main+1937 at main.c:691 0x4013CA51 __libc_start_main+221 0x08060011 _start+33
ERROR: [FREOPN]: memcpy: attempt to perform operation on free memory
And give this sumup and the end: top 31 unfreed memory entries in leak table:
bytes count location -------- ------ -------- 658496 972 debug_xalloc 288984 98 optimize_program 131324 1 main 120016 13 alloc_more_short_pike_string0 55584 18 alloc_more_pike_type 32680 2 alloc_more_program 26080 186 low_allocate_array 16296 1 alloc_more_pike_frame 13328 1 alloc_more_short_pike_string1 8516 11 realloc_unlinked_string 8176 1 alloc_more_object 8176 1 alloc_more_mapping 8176 1 alloc_more_callable 2064 1 alloc_more_callback 1847 6 _dl_new_object 1712 12 0x40145AFB 1552 1 alloc_more_destroy_called_mark 512 1 grow_fds 508 1 low_init_destroy_called_mark_hash 256 1 set_backend_for_fd 192 3 _dl_check_map_versions 173 1 0x401454FF 172 3 _dl_map_object_deps 128 1 __pthread_setspecific 100 2 _dl_map_object 60 1 0x401467EF 27 1 open_path 24 4 __strdup 16 1 0x400841F2 12 1 decompose_rpath 8 1 MY_FD_SET 1385195 1348 total
/ Martin Stjernholm, Roxen IS
Previous text:
2003-06-06 14:24: Subject: Post-padding overwritten
Hi,
I've compiled Pike with --with-dmalloc --with-dmalloc-malloc-leaks --with-checker --with-rtldebug and when I load Caudium I get the following error when it loads one of the Camas modules:
Loading camas_tags... Post-padding overwritten for block at 0xac7bda0 (size 20)! **Location: 0xac7bda0 Type: unknown Refs: 0 gc generation: 11/11 gc pass: 0/0 *** peep.c:187 (1 times) *** pike_memory.c:570 (1 times) **Cannot describe block of unknown type 247
Then the pike process exit. The previous modules loads without warning. Can you tell me what this mean ?
-- David Gourdelier
/ Brevbäraren
Valgrind fails with the error valgrind: the `impossible' happened: unhandled x86 opcode Basic block ctr is approximately 3150000
Compile with less processor optimizations, and/or use a newer valgrind. (Might not work if you use precompiled libraries like NVIDIAs OpenGL which uses SSE, which valgrind doesn't support.)
So I fail back to mtrace() and mpatrol. I run both when starting Hilfe and exiting immediatly. Both shows there are some leaks.
Have you compiled with --with-debug-malloc when you get those leak reports? Pike normally doesn't bother to free everything just before exit since the OS does that anyway, so it only happens when dmalloc or some other special debug modes are used (see DO_PIKE_CLEANUP in global.h).
Additionnaly mpatrol shows the following error several times:
MEMCOPY: memcpy (0x082D6390, 0x082D6714, 0 bytes, 0x00) [-|-|-]
Just a warning about copying a zero length block. Nothing important but I've added a simple check to 7.5 to avoid it.
ERROR: [FREOPN]: memcpy: attempt to perform operation on free memory
Sounds bad, but is this all? It's not much use without a location.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-06-07 11:17: Subject: Re: Post-padding overwritten
Hello,
Dmalloc has discovered that the postpadding of a block has been overwritten, probably due to a buffer overrun in the code that allocated the block. The two linenumbers you see are positions that have handled it.
I am afraid it's not the only point where there is a problem.
To locate bugs of that kind I suggest you run with Valgrind. It'll detect the overwriting directly instead and give you a backtrace showing exactly where it occurs.
Valgrind fails with the error valgrind: the `impossible' happened: unhandled x86 opcode Basic block ctr is approximately 3150000
So I fail back to mtrace() and mpatrol. I run both when starting Hilfe and exiting immediatly. Both shows there are some leaks.
The output from mtrace can be seen at http://www.iteam.org/~tux/pike.trace.txt and output from mpatrol is at http://www.iteam.org/~tux/pike.trace2.txt
Additionnaly mpatrol shows the following error several times:
MEMCOPY: memcpy (0x082D6390, 0x082D6714, 0 bytes, 0x00) [-|-|-] 0x080E3B5F optimize_program+707 at program_areas.h:20 0x080E54AF end_first_pass+559 at program.c:2516 0x080E5558 debug_end_program+28 at program.c:2572 0x080E9D7F init_program+555 at program.c:6199 0x080C34A5 main+1937 at main.c:691 0x4013CA51 __libc_start_main+221 0x08060011 _start+33
ERROR: [FREOPN]: memcpy: attempt to perform operation on free memory
And give this sumup and the end: top 31 unfreed memory entries in leak table:
bytes count location
658496 972 debug_xalloc 288984 98 optimize_program 131324 1 main 120016 13 alloc_more_short_pike_string0 55584 18 alloc_more_pike_type 32680 2 alloc_more_program 26080 186 low_allocate_array 16296 1 alloc_more_pike_frame 13328 1 alloc_more_short_pike_string1 8516 11 realloc_unlinked_string 8176 1 alloc_more_object 8176 1 alloc_more_mapping 8176 1 alloc_more_callable 2064 1 alloc_more_callback 1847 6 _dl_new_object 1712 12 0x40145AFB 1552 1 alloc_more_destroy_called_mark 512 1 grow_fds 508 1 low_init_destroy_called_mark_hash 256 1 set_backend_for_fd 192 3 _dl_check_map_versions 173 1 0x401454FF 172 3 _dl_map_object_deps 128 1 __pthread_setspecific 100 2 _dl_map_object 60 1 0x401467EF 27 1 open_path 24 4 __strdup 16 1 0x400841F2 12 1 decompose_rpath 8 1 MY_FD_SET 1385195 1348 total/ Martin Stjernholm, Roxen IS
Previous text:
2003-06-06 14:24: Subject: Post-padding overwritten
Hi,
I've compiled Pike with --with-dmalloc --with-dmalloc-malloc-leaks --with-checker --with-rtldebug and when I load Caudium I get the following error when it loads one of the Camas modules:
Loading camas_tags... Post-padding overwritten for block at 0xac7bda0 (size 20)! **Location: 0xac7bda0 Type: unknown Refs: 0 gc generation: 11/11 gc pass: 0/0 *** peep.c:187 (1 times) *** pike_memory.c:570 (1 times) **Cannot describe block of unknown type 247
Then the pike process exit. The previous modules loads without warning. Can you tell me what this mean ?
-- David Gourdelier
/ Brevbäraren
/ Brevbäraren
Compile with less processor optimizations, and/or use a newer valgrind. (Might not work if you use precompiled libraries like NVIDIAs OpenGL which uses SSE, which valgrind doesn't support.)
Valgrind CVS does handle SSE/MMX/3dnow.
/ Per Hedbor ()
Previous text:
2003-06-09 18:40: Subject: Re: Post-padding overwritten
Valgrind fails with the error valgrind: the `impossible' happened: unhandled x86 opcode Basic block ctr is approximately 3150000
Compile with less processor optimizations, and/or use a newer valgrind. (Might not work if you use precompiled libraries like NVIDIAs OpenGL which uses SSE, which valgrind doesn't support.)
So I fail back to mtrace() and mpatrol. I run both when starting Hilfe and exiting immediatly. Both shows there are some leaks.
Have you compiled with --with-debug-malloc when you get those leak reports? Pike normally doesn't bother to free everything just before exit since the OS does that anyway, so it only happens when dmalloc or some other special debug modes are used (see DO_PIKE_CLEANUP in global.h).
Additionnaly mpatrol shows the following error several times:
MEMCOPY: memcpy (0x082D6390, 0x082D6714, 0 bytes, 0x00) [-|-|-]
Just a warning about copying a zero length block. Nothing important but I've added a simple check to 7.5 to avoid it.
ERROR: [FREOPN]: memcpy: attempt to perform operation on free memory
Sounds bad, but is this all? It's not much use without a location.
/ Martin Stjernholm, Roxen IS
Cool. Time to compile a new set of Valgring/Cachegring/KCachegrind.
/ Peter Bortas
Previous text:
2003-06-09 18:53: Subject: Re: Post-padding overwritten
Compile with less processor optimizations, and/or use a newer valgrind. (Might not work if you use precompiled libraries like NVIDIAs OpenGL which uses SSE, which valgrind doesn't support.)
Valgrind CVS does handle SSE/MMX/3dnow.
/ Per Hedbor ()
Valgrind fails with the error valgrind: the `impossible' happened: unhandled x86 opcode Basic block ctr is approximately 3150000
Compile with less processor optimizations, and/or use a newer valgrind.
Or an older valgrind. I also got this when I upgraded valgrind a while back.
/ Martin Nilsson (lambda)
Previous text:
2003-06-09 18:40: Subject: Re: Post-padding overwritten
Valgrind fails with the error valgrind: the `impossible' happened: unhandled x86 opcode Basic block ctr is approximately 3150000
Compile with less processor optimizations, and/or use a newer valgrind. (Might not work if you use precompiled libraries like NVIDIAs OpenGL which uses SSE, which valgrind doesn't support.)
So I fail back to mtrace() and mpatrol. I run both when starting Hilfe and exiting immediatly. Both shows there are some leaks.
Have you compiled with --with-debug-malloc when you get those leak reports? Pike normally doesn't bother to free everything just before exit since the OS does that anyway, so it only happens when dmalloc or some other special debug modes are used (see DO_PIKE_CLEANUP in global.h).
Additionnaly mpatrol shows the following error several times:
MEMCOPY: memcpy (0x082D6390, 0x082D6714, 0 bytes, 0x00) [-|-|-]
Just a warning about copying a zero length block. Nothing important but I've added a simple check to 7.5 to avoid it.
ERROR: [FREOPN]: memcpy: attempt to perform operation on free memory
Sounds bad, but is this all? It's not much use without a location.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se
-
David Gourdelier -
Martin Nilsson (lambda) ＠ Pike (-) developers forum -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum