I test Mesa from CVS on a nightly basis by building it and using it to run a VTK dashboard. Recently I upgraded the version of glibc on my test system to 2.3.5 and started getting crashes with this error: *** glibc detected *** free(): invalid pointer: 0x420c7400 *** Here is the interesting part of the stack trace: #6 0x41dec309 in malloc_printerr () from /lib/libc.so.6 #7 0x41decda1 in free () from /lib/libc.so.6 #8 0x412953ac in _mesa_free () from /home/kingb/Nightly/Mesa-build/lib/libMesaGL.so.1 #9 0x41309309 in _tnl_free_vertices () from /home/kingb/Nightly/Mesa-build/lib/libMesaGL.so.1 #10 0x41393d3d in _swsetup_DestroyContext () from /home/kingb/Nightly/Mesa-build/lib/libMesaGL.so.1 #11 0x413d84fd in XMesaDestroyContext () from /home/kingb/Nightly/Mesa-build/lib/libMesaGL.so.1 #12 0x413d4661 in Fake_glXDestroyContext () from /home/kingb/Nightly/Mesa-build/lib/libMesaGL.so.1 #13 0x413d0279 in glXDestroyContext () from /home/kingb/Nightly/Mesa-build/lib/libMesaGL.so.1 #14 0x402166f1 in vtkXOpenGLRenderWindow::Finalize (this=0x8077758) I performed a binary search back through time in CVS and found that the problem was introduced on October 18, 2005 when mm.h, mm.c, and execmem.c were added. If I do cvs diff -D "Oct 17 17:00:00 EST 2005" -D "Oct 18 17:00:00 EST 2005" the full set of changes are shown. With sources from the 17th the error does not occur, and with sources on the 18th the problem occurs. The problem is exposed by some new debugging check that was added in glibc 2.3.5, so it did not appear when I was using an older glibc. FYI, it looks like the changes were put on the Mesa 6.4 release branch, so it probably contains the bug also.
Brad, I'm seeing the same error here using glibc 2.2.93 (Fedora Core 4). I think the safest thing to do right now is to disable line 497: FREE((void *)fp->func); At first glance, I'd replace FREE with _mesa_exec_free() but I don't know if we can be sure that fp->func always points to memory allocated with _mesa_exec_malloc() or if might sometimes point to an ordinary C function. I'll check in a "fix" that simply disables that line for now. It won't be a huge leak. Maybe Keith can comment.
Strange, I wonder why I didn't get it with my previous glibc, which was definately newer than 2.2.93. Anyway, if you are not sure what sets fp->func then you could create an additional member fp->freefunc that can be set to a function that frees fp->func. I cannot comment on whether this is a good design for your case or not but I wanted to suggest the idea.
*** Bug 5185 has been marked as a duplicate of this bug. ***
This was fixed in 6.4.1.
The fix has been working in the nightly development version for quite some time now.
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.