#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)
Change History (25)
by , 12 years ago
| Attachment: | GLTeapot-1080-debug-22-02-2013-18-45-57.report added |
|---|
by , 12 years ago
| Attachment: | Haiku3d-1164-debug-22-02-2013-18-46-40.report added |
|---|
Haiku3d debugger crash report
follow-up: 2 comment:1 by , 12 years ago
| Component: | Applications/GLTeapot → Kits/OpenGL Kit |
|---|---|
| Version: | R1/alpha4.1 → R1/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?
comment:2 by , 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 , 12 years ago
Hm, perhaps this is some sorto of 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.
comment:4 by , 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 , 12 years ago
| Platform: | x86-64 → x86 |
|---|
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:8 by , 12 years ago
| Priority: | normal → critical |
|---|
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 , 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 , 12 years ago
| Attachment: | screenshot1.png added |
|---|
screenshot of backtrace (as far back as it will go)
by , 12 years ago
| Attachment: | GLInfo-601-debug-14-03-2013-22-27-32.report added |
|---|
glinfo debugger output showing struct values
comment:10 by , 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.
comment:11 by , 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 , 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 , 12 years ago
comment:15 by , 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:17 by , 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.
GLTeapot debugger crash report