Re: [Annoyance] Thread still present after leaving balsa

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;
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.



Attachment: pgpaj9dVTKK8E.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]