OpenGL demo applications crash

[matjako]

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.

[matjako]

GLTeapot debugger crash report

[matjako]

Haiku3d debugger crash report

[kallisti5]

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?

[matjako]

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.

[matjako]

Hm, perhaps this 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

[kallisti5]

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)

[kallisti5]

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)

[matjako]

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

[anevilyak]

(In #9521) Duplicate of #9473

[kallisti5]

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

[kallisti5]

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?

[kallisti5]

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

[kallisti5]

glinfo stdout with mesa debugging

[kallisti5]

glinfo debugger output showing struct values

[kallisti5]

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.

[kallisti5]

fFrameBuffer width

[kallisti5]

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?

[kallisti5]

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.

[kallisti5]

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

[kallisti5]

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

[kallisti5]

*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.

[kallisti5]

resolved in hrev45386

[kallisti5]

first go at it

[kallisti5]

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.

[kallisti5]

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