[jazzplusplus-devel] Core dumping

[Matt K. <ra...@ch...>]

Perhaps this is a tad premature, but:

Every time I run the latest and greatest build of JAZZ, when I perform
a File -> Exit, it dumps core.

There is a problem with some delete calls in jazz.cpp, which where shown
by valgrind.  I fixed those, but now I get a seg fault.  Valgrind says:

==18348== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
NumConfigNames: 66
==18348==
==18348== Invalid read of size 4
==18348==    at 0x405B79B2: wxVariant::~wxVariant() (in 
/usr/X11R6/lib/libwx_gtk-2.4.so.0.0.0)
==18348==    by 0x405BC2AF: __tcf_4 (in 
/usr/X11R6/lib/libwx_gtk-2.4.so.0.0.0)
==18348==    by 0x408EAD89: __cxa_finalize (in /lib/libc.so.6)
==18348==    by 0x40371061: (within /usr/X11R6/lib/libwx_gtk-2.4.so.0.0.0)
==18348==    Address 0xFFFFFFF4 is not stack'd, malloc'd or free'd
Segmentation fault (core dumped)


I'm guessing this is being caused by a destructor in a global class
which ends up calling the wxVariant destructor.  But, it leaves no
other trace.

The gdb stack trace looks similar:
(gdb) where
#0  0x403c59b2 in wxVariant::~wxVariant() ()
    from /usr/X11R6/lib/libwx_gtk-2.4.so.0
#1  0x403ca2b0 in __tcf_4 () from /usr/X11R6/lib/libwx_gtk-2.4.so.0
#2  0x40723d8a in __cxa_finalize () from /lib/libc.so.6
#3  0x4017f062 in __do_global_dtors_aux ()
    from /usr/X11R6/lib/libwx_gtk-2.4.so.0
#4  0x40444bc6 in _fini () from /usr/X11R6/lib/libwx_gtk-2.4.so.0
#5  0x4000b9a0 in _dl_fini () from /lib/ld-linux.so.2
#6  0x40723b0f in exit () from /lib/libc.so.6
#7  0x4070d8b6 in __libc_start_main () from /lib/libc.so.6

This could be a bugger to find.

Oh.  I guess I meant to ask if anyone else is seeing this?

The fix I put in for the delete problem is in jazz.cpp:

diff -r1.6 jazz.cpp
274c274,275
<       delete [] Names[i];
---
 >       if (Names[i])
 >           delete  Names[i];


More in context:

tConfig::~tConfig()
{
    int i;
    for (i = 0; i < NumConfigNames; i++)
    {
       if (Names[i])
           delete  Names[i];
    }
}


I'm also chasing an odd new/delete mismatch in track.cpp which is being
caused by old code.  I'll post the fix when I find it.

Matt