On Wed, 2009-12-02 at 09:05 -0800, Roland Scheidegger wrote:
> Hi,
>
> I've come across some bug (which I thought might be related to the
> gallium-noblocks branch, but it's not) which caused a segfault but only
> when not using debug builds. I think this is the same issue Vinson was
> seeing some time ago. Looks like a impossible backtrace:
>
> #0 st_texture_image_copy (pipe=0x612640, dst=0x0,
> dstLevel=<value optimized out>, src=0x6e1dd0, face=0)
> at src/mesa/state_tracker/st_texture.c:306
> #1 0x00007ffff759b383 in copy_image_data_to_texture (
> ctx=<value optimized out>, pipe=<value optimized out>, tObj=0x6919d0,
> needFlush=<value optimized out>)
> at src/mesa/state_tracker/st_cb_texture.c:1673
> #2 st_finalize_texture (ctx=<value optimized out>,
> pipe=<value optimized out>, tObj=0x6919d0, needFlush=<value
> optimized out>)
> at src/mesa/state_tracker/st_cb_texture.c:1807
> #3 0x00007ffff758fd9d in finalize_textures (st=0x68a9c0)
> at src/mesa/state_tracker/st_atom_texture.c:144
>
> Segfault seems to be because dst is 0x0, but if you look at the call
> stack it is easy to see this is impossible.
> That would point to gcc optimizer issue (using gcc 4.4.1), except there
> are quite a few warnings during compile, especially about violating
> strict-aliasing rules...
> So, in the gallium.py scons file there's actually this:
> if debug:
> ccflags += ['-O0', '-g3']
> elif env['CCVERSION'].startswith('4.2.'):
> # gcc 4.2.x optimizer is broken
> print "warning: gcc 4.2.x optimizer is broken -- disabling
> optimizations"
> ccflags += ['-O0', '-g3']
> else:
> ccflags += ['-O3', '-g3']
>
>
> So I added -fno-strict-aliasing and indeed, segfault is gone. Hence I
> believe this is incorrectly accusing the gcc 4.2 optimizer, whereas it's
> actually a code bug, and certainly it is not restricted to gcc 4.2
> (unless this addressed a different problem).
It addressed a different problem. Type
git show bb8f3090ba37aa3f24943fdb43c4120776289658
to see explanation of it.
> Not quite sure though why the code violates strict-aliasing rules though
> in all places - about half of the warnings are from pipe_reference,
> (p_refcount.h:85). Not sure if all warnings are actually real issues,
> and not sure how this should be fixed (should we try to fix this for
> real or just force -fno-strict-aliasing).
I read (forgot where) that gcc strict aliasing warnings don't catch all
cases.
I've seen strict aliasing assumption causing bugs in other gallium
components. It seems endemic to our code. Unless we actively decidee to
go and chase the strict aliasing bugs now we should add
-fno-strict-aliasing to all our builds.
Jose
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
