Bug 5131

Summary:	Free of invalid pointer in _mesa_free
Product:	Mesa	Reporter:	Brad King <brad.king>
Component:	Mesa core	Assignee:	mesa-dev
Status:	VERIFIED FIXED	QA Contact:
Severity:	critical
Priority:	high	CC:	chewi
Version:	git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Brad King 2005-11-23 09:26:08 UTC

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.

Comment 1 Brian Paul 2005-11-23 10:23:47 UTC

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.

Comment 2 Brad King 2005-11-23 10:54:56 UTC

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.

Comment 3 Michel Dänzer 2005-12-01 03:47:24 UTC

*** Bug 5185 has been marked as a duplicate of this bug. ***

Comment 4 Brian Paul 2006-01-20 01:53:14 UTC

This was fixed in 6.4.1.

Comment 5 Brad King 2006-01-20 01:59:30 UTC

The fix has been working in the nightly development version for quite some time now.

Comment 6 Adam Jackson 2009-08-24 12:23:36 UTC

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.