Bug 30238 - [glsl2] 3DMarkMobileES2.0 can't run with segment fault
Summary: [glsl2] 3DMarkMobileES2.0 can't run with segment fault
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Kenneth Graunke
QA Contact:
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: 29044
  Show dependency treegraph
 
Reported: 2010-09-17 02:43 UTC by zhao jian
Modified: 2011-03-07 19:16 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description zhao jian 2010-09-17 02:43:25 UTC
System Environment:
--------------------------
Platform:       capella
os:             32 bit
Libdrm:		(master)2.4.21-21-g7ec9a1effa4f551897f91f3b017723a8adf011d9
Mesa:		(master)9476efe77ff196993937c3aa2e5bca725ceb0b41
Xserver:	(master)c768cdda92696b636c10bb2df64167d5274b4b99
Xf86_video_intel:	(master)08c2caca48323d6d5701dcef3486f850619d7905
Cairo:		(master)36018ac7ce4285367d3168fc09a0d046c04e238e
Kernel_unstable:  (for-linus)76be97c1fc945db08aae1f1b746012662d643e97

Bug detailed description:
-------------------------
We run 3DMarkMobileES2.0 on T410 32bit system with the newest code on mesa master branch, it can't run with "Segmentation fault". I find it can run without segmentation fault before glsl2 branch merge to master branch. And with the merge point of glsl2 to master or on glsl2 branch, it will has such issue. 
There is a message in dmesg: 3DMarkMobileES2[25360]: segfault at 4 ip 080691be sp bfb316c0 error 4 in 3DMarkMobileES20[8048000+67000]

The backtrace is as following. 
Program received signal SIGSEGV, Segmentation fault.
0x080691be in oes_draw_elements (engine=0x80b3740, mode=4, count=768,
    type=5123, indices=0x2c7a2)
    at ../../common/fm_oes_engine/oes/oes_request.c:104
104             oes_gl_disable_vertex_attrib_array(shader_attribute->slot);
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-10.fc13.i686 glibc-2.12-1.i686 libXdmcp-1.0.3-3.fc13.i686 libgcc-4.4.4-2.fc13.i686 libstdc++-4.4.4-2.fc13.i686 libtalloc-2.0.1-1.fc13.i686
(gdb) bt
#0  0x080691be in oes_draw_elements (engine=0x80b3740, mode=4, count=768,
    type=5123, indices=0x2c7a2)
    at ../../common/fm_oes_engine/oes/oes_request.c:104
#1  0x08065a1c in oes_batch_draw (player=0x80b7a48)
    at ../../common/fm_oes_engine/graphics/batch_draw.c:65
#2  0x080622aa in oes_transform_and_draw_object_batch (player=0x80b7a48,
    object_index=65, batch_index=216)
    at ../../common/fm_oes_engine/scene/object_set.c:68
#3  0x08062434 in oes_object_set_draw (player=0x80b7a48, object_set=0xb6c00170)
    at ../../common/fm_oes_engine/scene/object_set.c:118
#4  0x08064a23 in oes_scene_player_draw (player=0x80b7a48)
    at ../../common/fm_oes_engine/scene/scene_player_draw.c:68
#5  0x08076741 in render_scene (app=0x80b0010)
    at ../../common/fm_oes_player/src/render_scene.c:109
#6  0x0806c1e1 in app_update (app=0x80b0010)
    at ../../common/fm_oes_player/src/cycle.c:38
#7  0x0804c8ea in main ()
    at ../../configuration/img_linux/fm_system/linux_main.c:96

reproduce step: 
run the 3DMarkMobileES2.0 with newest code in mesa master or glsl2 branch.
Comment 1 Kenneth Graunke 2010-12-07 13:20:42 UTC
I can't reproduce this, sorry.  I tried building 3DMarkMobileES2.0 on my 64-bit Linux system and hit all kinds of build failures due to #include picking up 3DMark's "string.h" and "math.h" rather than the system headers.  After patching 17 different files I was able to get it to build, but it crashes at application startup, well before any real work is done.

So I'm not sure how to proceed.
Comment 2 Kenneth Graunke 2011-01-04 02:04:02 UTC
I don't believe this bug should delay the Q4 release.  ES is still a somewhat new and thus experimental feature (though working more and more each time!), and I don't think this is a regression from prior releases.  We also still haven't tracked it to a specific issue in our driver.

It still warrants looking into, but I don't think it's a top-priority bug.
Comment 3 Gordon Jin 2011-01-04 03:53:19 UTC
agree this doesn't block Q4 release. 

but note this is regression as the original description mentions this worked before glsl2 merge.
Comment 4 Kenneth Graunke 2011-01-18 14:08:47 UTC
It seems to run with Mesa master, which has Chad's fixes for dealing with the "precision" qualifier.
Comment 5 Kenneth Graunke 2011-03-02 15:10:36 UTC
Last I checked (some time ago) 3DMarkMobileES2.0 runs without crashing.  Closing this report.  There are likely other 3DMarkMobileES2.0 issues, but they can be opened as new reports.
Comment 6 zhao jian 2011-03-07 19:16:23 UTC
(In reply to comment #5)
> Last I checked (some time ago) 3DMarkMobileES2.0 runs without crashing. 
> Closing this report.  There are likely other 3DMarkMobileES2.0 issues, but they
> can be opened as new reports.

With the newest code in master branch and kernel in drm-intel-next, the 3DMarkMobileES2.0 was successfully begin to test instead of crashing. Tested with: 
Libdrm:         (master)2.4.24-6-g3b04c73650b5e9bbcb602fdb8cea0b16ad82d0c0
Mesa:           (master)6547253bd138db815173c00ca2dc220e8ad20ab1
Xserver:                (master)xorg-server-1.10.0-62-g628d16a92a7fa556fbb70bf4a4adf57ec05c190b
Xf86_video_intel:               (master)2.14.901
Cairo:          (master)f1d313e042af89b2f5f5d09d3eb1703d0517ecd7
Kernel: (drm-intel-next)710f957846cff998c681f3701f6f90eda896458f


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.