Cezary Morga wrote:
Mattia Barbon pisze:
I'm having a problem with Wx on some of the FreeBSD versions. While
compilation goes all the way fine make test fails miserably on almost
all test with core dump:
Which test pass?
Test 15_threads pass while 12_pod and zz_distrib are skipped.
Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0), function
arena_run_reg_dalloc, file
/opt/tinderbox/jails/8-CURRENT/src/lib/libc/stdlib/malloc.c, line 2543.
Abort (core dumped)
Is there a valgrind-alike for FreeBSD or at least a debugging memory
allocator of some sort (for example MacOSX malloc can be debugged by
setting some environment variables).
Well, there is valgrind for FreeBSD. Although...
===> valgrind-352_7 FreeBSD 8.x is unsupported.
...and this is 8.x where the problem first appeared, but it turns out
that the problem with memory allocation appears on 7.x as well, and the
reason it showed on 8.x is that only on this version libc is compiled
with malloc debuging on by default. Stable releases have this turned off
and thus don't dump core. So, I've given it a spin with valgrind on my
7.2 box (http://therek.net/wx/wx-malloc-valgrind.txt):
==97108== 1 errors in context 1 of 1:
==97108== Invalid write of size 4
==97108== at 0x3C007F13: (within /libexec/ld-elf.so.1)
==97108== by 0x3C018395: (within /libexec/ld-elf.so.1)
==97108== by 0x3C00811C: (within /libexec/ld-elf.so.1)
==97108== by 0x3C0061FB: (within /libexec/ld-elf.so.1)
==97108== Address 0xFFFFFFFC is not stack'd, malloc'd or free'd
==97108== IN SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Could you increase the stack frame count and retry? Just to see the
Perl/wxPerl code.
There is some MALLOC_OPTIONS environment variable
(http://www.freebsd.org/cgi/man.cgi?query=malloc&apropos=0&sektion=0&manpath=FreeBSD+8-current&format=html#TUNING)
bit similar to MacOSX (judging from what I found about it) but I lack
proper knowledge to be able to use it (quite like with valgrind :)).
Try with AJU and AZU; if you're lucky the program should fail close
to the problematic code.
I only managed to get the utrace entries, which show that the same
memory seems to be allocated twice:
3325 perl5.10.0 USER 0x284110a4 = malloc(4)
3325 perl5.10.0 USER 0x2843c050 = realloc(0x284110a4, 8)
<snip>
3325 perl5.10.0 USER 0x284110a4 = malloc(4)
When running core through gdb only informative (at least so I think)
message is:
Program terminated with signal 6, Aborted.
Can you get a stacktrace?
Yes, http://therek.net/wx/wx-malloc-core-backtrace.txt.
Since there are no function names there isn't much I can do with it...
probably the stack is corrupted, given there are addresses close to 0.
Regards.
Mattia
