Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#9473 closed bug (fixed)

OpenGL demo applications crash

Reported by: matjako Owned by: kallisti5
Priority: critical Milestone: R1
Component: Kits/OpenGL Kit Version: R1/Development
Keywords: crash mesa Cc:
Blocked By: Blocking: #9521
Platform: x86

Description

Both GLTeapot and Haiku3d crash with segment violation on _mesa_resize_framebuffer. I am using an AMD display controller reported as "Turks [Radeon HD 6570]", debug reports attached.

Attachments (7)

GLTeapot-1080-debug-22-02-2013-18-45-57.report (3.7 KB ) - added by matjako 12 years ago.
GLTeapot debugger crash report
Haiku3d-1164-debug-22-02-2013-18-46-40.report (4.0 KB ) - added by matjako 12 years ago.
Haiku3d debugger crash report
screenshot1.png (101.2 KB ) - added by kallisti5 12 years ago.
screenshot of backtrace (as far back as it will go)
stdout (855 bytes ) - added by kallisti5 12 years ago.
glinfo stdout with mesa debugging
GLInfo-601-debug-14-03-2013-22-27-32.report (16.4 KB ) - added by kallisti5 12 years ago.
glinfo debugger output showing struct values
Screenshot from 2013-03-17 16:16:59.png (148.7 KB ) - added by kallisti5 12 years ago.
fFrameBuffer width
execmem.c (3.9 KB ) - added by kallisti5 12 years ago.
first go at it

Download all attachments as: .zip

Change History (25)

by matjako, 12 years ago

GLTeapot debugger crash report

by matjako, 12 years ago

Haiku3d debugger crash report

comment:1 by kallisti5, 12 years ago

Component: Applications/GLTeapotKits/OpenGL Kit
Version: R1/alpha4.1R1/Development

Strange... what resolution / color space are you running on this monitor? (for example: 1024x768 @ 32-bit color)

Did you just start the OpenGL applications or do something in them to trigger the error?

in reply to:  1 comment:2 by matjako, 12 years ago

Replying to kallisti5:

Strange... what resolution / color space are you running on this monitor? (for example: 1024x768 @ 32-bit color)

1280x1024 32bpp, but it is the same in all resolutions

Did you just start the OpenGL applications or do something in them to trigger the error?

It crashes immediately, without creating a window.

comment:3 by matjako, 12 years ago

Hm, perhaps this is an AMD thing? I have also another HTPC with a Zacate APU, adapter reported as Wrestler [Radeon HD 6310]... same symptomps. Otherwise resolutions are reported and switched normally on both machines, on HTPC I need to use VGA output because the only alternative is HDMI.

Debug information for team /boot/system/demos/GLTeapot (267): CPU(s): 2x AMD C-Series Memory: 3.73 GiB total, 177.30 MiB used Haiku revision: hrev45315 Feb 22 2013 05:31:14 (BePC)

Loaded Images:

/boot/system/demos/GLTeapot (1904, Application) Text: 0x200000 - 0x210000, Data: 0x210000 - 0x213000 /boot/system/runtime_loader (1903, Library) Text: 0x100000 - 0x114000, Data: 0x114000 - 0x116000 /boot/system/lib/libbe.so (1905, Library) Text: 0x213000 - 0x493000, Data: 0x493000 - 0x516000 /boot/system/lib/libGL.so (1906, Library) Text: 0x516000 - 0x5c0000, Data: 0x5c0000 - 0x5d2000 /boot/system/lib/libgame.so (1907, Library) Text: 0x5d2000 - 0x5ec000, Data: 0x5ec000 - 0x5f3000 /boot/system/lib/libroot.so (1908, Library) Text: 0x5f3000 - 0x6ba000, Data: 0x6ba000 - 0x704000 /boot/system/lib/libstdc++.hrev4.so (1909, Library) Text: 0x704000 - 0x734000, Data: 0x734000 - 0x741000 /boot/system/lib/libicudata.so.48.1.1 (1910, Library) Text: 0x741000 - 0x18dc000, Data: 0x18dc000 - 0x18e2000 /boot/system/lib/libicui18n.so.48.1.1 (1911, Library) Text: 0x18e2000 - 0x1aeb000, Data: 0x1aeb000 - 0x1b38000 /boot/system/lib/libicuio.so.48.1.1 (1912, Library) Text: 0x1b38000 - 0x1b40000, Data: 0x1b40000 - 0x1b42000 /boot/system/lib/libicule.so.48.1.1 (1913, Library) Text: 0x1b42000 - 0x1b7a000, Data: 0x1b7a000 - 0x1b81000 /boot/system/lib/libiculx.so.48.1.1 (1914, Library) Text: 0x1b81000 - 0x1b8b000, Data: 0x1b8b000 - 0x1b8e000 /boot/system/lib/libicutu.so.48.1.1 (1915, Library) Text: 0x1b8e000 - 0x1bad000, Data: 0x1bad000 - 0x1be2000 /boot/system/lib/libicuuc.so.48.1.1 (1916, Library) Text: 0x1be2000 - 0x1d1d000, Data: 0x1d1d000 - 0x1d46000 /boot/system/lib/libnetwork.so (1917, Library) Text: 0x1d46000 - 0x1d88000, Data: 0x1d88000 - 0x1d8b000 /boot/system/lib/libmedia.so (1918, Library) Text: 0x1d8b000 - 0x1e18000, Data: 0x1e18000 - 0x1e35000 /boot/system/lib/libroot-addon-icu.so (1919, Library) Text: 0x1e35000 - 0x1e45000, Data: 0x1e45000 - 0x1e48000 /boot/system/add-ons/opengl/Legacy Software Rasterizer (1922, Add-on) Text: 0x1e48000 - 0x209b000, Data: 0x209b000 - 0x20b0000 commpage (28, System) Text: 0xffff0000 - 0xffff8000, Data: 00000000 - 00000000

Active Threads:

GLTeapot (main), id: 267, state: Exception (Segment violation)

Frame IP Function Name ----------------------------------------------- 00000000 00000000 ?

Frame memory:

0x7ffee3dc 0x1e8f65e _mesa_resize_framebuffer + 0x82 0x7ffee414 0x1e63e7f MesaSoftwareRenderer::_CheckResize() + 0x43 0x7ffee454 0x1e63458 MesaSoftwareRenderer::LockGL() + 0xf8 0x7ffee7b4 0x1e631df 20MesaSoftwareRendererP7BGLViewUlP13BGLDispatcher + 0x4b7 0x7ffee7f4 0x1e62cd9 instantiate_gl_renderer + 0x31 0x7ffee89c 0x540728 GLRendererRoster::CreateRenderer(entry_ref&) + 0xfc 0x7ffee98c 0x540186 GLRendererRoster::AddPath(char*) + 0x196 0x7ffee9fc 0x53ff82 GLRendererRoster::AddDefaultPaths() + 0xa2 0x7ffeec5c 0x53fce9 16GLRendererRosterP7BGLViewUl + 0x275 0x7ffeecac 0x53e1fb 7BGLViewG5BRectPCcUlUlUl + 0x117 0x7ffeed14 0x2095a8 10ObjectViewG5BRectPCcUlUl + 0x48 0x7ffeeef4 0x20bde0 12TeapotWindowG5BRectPCc11window_typeUl + 0x334 0x7ffeef44 0x20f35c 9TeapotAppPCc + 0xc8 0x7ffeef84 0x20f1ef main + 0x33 0x7ffeefac 0x206e0e _start + 0x56 0x7ffeefdc 0x10626c runtime_loader + 0x124 00000000 0x7ffeefec ?

Registers:

eip: 0x00000000 esp: 0x7ffee3a0 ebp: 0x7ffee3dc eax: 0x00000000 ebx: 0x0209bc50 ecx: 0x18081cc0 edx: 0x1802ee40 esi: 0x180b8a58 edi: 0x00000000

cs: 0x001b ds: 0x0023 es: 0x0023 fs: 0x006b gs: 0x0023 ss: 0x0023

direct daemon , id: 271, state: Running team 267 debug task , id: 272, state: Running

Last edited 12 years ago by matjako (previous) (diff)

comment:4 by kallisti5, 12 years ago

I just noticed that x86-64 was selected for this case... how are you using the Legacy Software Rasterizer? (that is gcc2 only which doesn't offer non-x86 support)

comment:5 by kallisti5, 12 years ago

Platform: x86-64x86

The backtraces say BePC... so i'm assuming x86_64 was a mistake (you only select it if you are running the 64-bit gcc4 builds)

comment:6 by matjako, 12 years ago

True, it should be x86 - i am running a gcc2 hybrid nightly.

comment:7 by anevilyak, 12 years ago

Blocking: 9521 added

(In #9521) Duplicate of #9473

comment:8 by kallisti5, 12 years ago

Priority: normalcritical

Ok. I was finally able to reproduce this in VirtualBox on hrev45361. To be honest, I have *no* idea what caused this as nothing changed recently in the gcc2 GL rendering.

Looking into this now

comment:9 by kallisti5, 12 years ago

I tried using the previous Mesa 7.8.2 optionalbuildpackage from 2012... same result. Definitley not related to the recent Mesa rebuild.

I wonder if this is related to the recent optimization changes?

by kallisti5, 12 years ago

Attachment: screenshot1.png added

screenshot of backtrace (as far back as it will go)

by kallisti5, 12 years ago

Attachment: stdout added

glinfo stdout with mesa debugging

by kallisti5, 12 years ago

glinfo debugger output showing struct values

comment:10 by kallisti5, 12 years ago

My only guess so far is that att->Renderbuffer or AllocStorage is NULL somehow. (see Screenshot1.png) Still not 100% this is a complete backtrace. I've enabled as many debugging symbols as I can. (Mesa build package debug symbols, OpenGL kit debugging)

The AllocStorage code we call is painfully simple in the swrast_legacy renderer.

This all also doesn't explain why we're suddenly seeing this issue. Nothing has changed in swrast_legacy in recent history. I need to do a bisect when I get some free time.

by kallisti5, 12 years ago

fFrameBuffer width

comment:11 by kallisti5, 12 years ago

I have *no* idea what is messing up the fFrameBuffer->width. This really doesn't make sense. We calloc fFrameBuffer and i've confirmed after calloc it is 0x0. We then later access it and it jumps to 33710880x0.

I wonder if this is SSE related in some way?

comment:12 by kallisti5, 12 years ago

I've tracked the corruption of fFrameBuffer->width to _mesa_initialize_window_framebuffer at the following location: http://cgit.haiku-os.org/haiku/tree/src/add-ons/opengl/swrast_legacy/MesaSoftwareRenderer.cpp#n285

Still not sure of the cause.

comment:13 by kallisti5, 12 years ago

It looks like the AllocStorage function pointer is NULL as per debugger (this doesn't make sense though as I know we set it)

I confirmed that this doesn't occur in hrev45249

I need to git bisect between hrev45249 and hrev45315

comment:14 by kallisti5, 12 years ago

git bisect reports that hrev45297 is the first bad commit :\

comment:15 by kallisti5, 12 years ago

*FINALLY* found the regression.

hrev45297 removes the --no-warnings flag *and* stops setting the swrast_legacy defines. Thanks to stpere for spotting the error in irc after my bisect!

Testing the solution now.

comment:16 by kallisti5, 12 years ago

Resolution: fixed
Status: newclosed

resolved in hrev45386

by kallisti5, 12 years ago

Attachment: execmem.c added

first go at it

comment:17 by kallisti5, 12 years ago

attached is my first go at execmem.c. I haven't tested it (or even tried compiling it yet) but wanted to get it somewhere public.

I plan on testing this tonight.

comment:18 by kallisti5, 12 years ago

Please ignore.. this was attached to the wrong OpenGL bug :(

Note: See TracTickets for help on using tickets.