On 08/01/2009 01:03:25 PM Sat, Pawel Salek wrote: [ snip ]
This is the (in)fameous xcb deadlock problem - or can it be a heap corruption? One way to find out is to run either:env MALLOC_CHECK_=2 balsa or using valgrind.
I've been seeing these too. Running with MALLOC_CHECK_=2 reveals no errors before the segv, so it doesn't appear to be misuse of the heap. The segv is typically in code like:
(gdb) l
4306 malloc_consolidate(av);
4307 else {
4308 bck = victim->bk;
4309 set_inuse_bit_at_offset(victim, nb);
4310 bin->bk = bck;
4311 bck->fd = bin;
4312
4313 if (av != &main_arena)
4314 victim->size |= NON_MAIN_ARENA;
4315 check_malloced_chunk(av, victim, nb);
and in line 4311, bck is NULL. So victim is corrupt, which looks like a
glibc bug.
But...running with valgrind always quits shortly after the main window is displayed, with
Assertion 'pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting.
Comments on a bug (can't find it today!) suggested exporting CANBERRA_SERVER=NULL, which does indeed allow valgrind balsa to run, but also revealing no memory allocation issues.
After exporting that, however, I can no longer reproduce the segv! That suggests that something in the sound stack may be corrupting the heap, in some way that's not detected by MALLOC_CHECK_. Anyway, for me, so far, that's providing a work-around.
Best, Peter
Attachment:
pgpaj9dVTKK8E.pgp
Description: PGP signature