On 02.12.2009 18:33, José Fonseca wrote:
> 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.
Ok.
>
>> 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.
gcc man page states this (-Wstrict-aliasing=n). Says though (gcc 4.4.1)
with n=3 (default) there should be "very few false positives and few
false negatives".
>
> 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.
ok. I guess though there's no guarantee it won't break other compilers
where we don't have set any flags for this.
Roland
------------------------------------------------------------------------------
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
