On 08/05/2010 04:30 PM, tom fogal wrote:
"Kevin H. Hobbs"<hob...@ohiou.edu> writes:
On 08/04/2010 05:58 PM, tom fogal wrote:
If you can find the commit that started the trouble (using git
bisect), that might shed some light.
With my script adjusted to only report when the test started
segfaulting git bisect reports :
91c37599f621a0ec498c0f0add14f16470ca852b is the first bad commit
commit 91c37599f621a0ec498c0f0add14f16470ca852b
Author: Brian Paul<bri...@vmware.com>
Date: Fri Jul 2 18:18:15 2010 -0600
osmesa: remove old renderbuffer before adding new
=20
Fixes fd.o bug 10966 when OSMesaMakeCurrent() was called twice.
=20
NOTE: This is a candidate for the 7.8 branch.
Well, that sucks. I just started putting together commits for 7.8
recently, specifically because I/we need *that* one commit ;)
Is your test multithreaded, by any chance?
It looked like some sort of strange link/memory corruption to me
before, but valgrind didn't turn up much, and this commit really does
so little; it seems odd to blame memory corruption in this case.
Brian, any ideas?
Yeah, this is weird.
Kevin, you seem to have identified two potential commits that caused
trouble:
91c37599f621a0ec498c0f0add14f16470ca852b
and
36b3a8bd5a317ab297f44b19fd14c7e76ec2fc77
You should go to the head of the Mesa git tree and then undo each of
those changes one by one (either git-revert or patch -R, etc) and
re-test to be absolutely sure that one or the other is causing the
segfault.
My other hunch is something is duplicated in the libOSMesa and libGL
libraries that's causing things to blow up in general.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
