This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Simple test case (sdl_opengl_crash_testcase.cpp, text/plain, 2006-06-21 20:15:24 +0000, 1976 bytes)

Reported in version: 1.2.10
Reported for operating system, platform: Windows (XP), x86

Comments on the original bug report:

On 2006-06-21 20:10:51 +0000, HyperHacker wrote:

My system contains both an AGP and a PCI video card, both of which have monitors connected. The PCI card is set as primary in the BIOS (otherwise it won't work), but the AGP card is set as primary in Windows. Both cards pass all DirectDraw and Direct3D tests in dxdiag, and DirectX works fine. However, calling SDL_SetVideoMode with the SDL_OPENGL flag causes an access violation if the PCI card is enabled.

I have experienced the same problem using both a Cirrus Logic 1MB PCI card with no 3D capabilities, and an ATI Rage XL 8MB PCI card with basic 3D capabilities (which I am currently using). Either way, the primary card is a Volari XGI83 128MB AGP with AGP texture acceleration, so the PCI card's capabilities shouldn't be a factor.
The error occurrs in both windowed and fullscreen mode at 640x480 with 8 or 32 bits per pixel, using hardware or software surfaces. Specifying SDL_ANYFORMAT, SDL_ASYNCBLIT, SDL_DOUBLEBUF or SDL_OPENGLBLIT (in place of SDL_OPENGL) in the SDL_SetVideoMode call doesn't help.

I can disable either video card from within Windows from the Display control panel:

1. Select the monitor connected to the card that should remain enabled, and make it the primary display.
2. Select the monitor that will be disabled, and uncheck "Extend my desktop onto this monitor".
   The program works on either card so long as only one is enabled.

Here is the exception information and register status from the program. Unfortunately I can't obtain a stack dump.

FATAL ERROR: Access violation at 0x69004B10 in thread 2744
Exception details: Could not read memory at 0x69004B10
SgG=00000000 SgF=0000003B SgE=00000023 SgD=00000023 SgC=0000001B SgS=00000023
EDI=00000000 ESI=00040000 EBX=0023FB70 EDX=00000002 ECX=00040001 EAX=00530650
EBP=0023FB58 EIP=69004B10 ESP=0023FB28
Dr0=00000000 Dr1=00000000 Dr2=00000000 Dr3=00000000 Dr6=00000000 Dr7=00000000
Extended registers:
reg# +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
0000: 7F 03 00 00 00 00 65 00 00 00 00 00 A4 38 35 EE
0010: 01 00 00 00 BC 18 80 BF 80 1F 00 00 D9 18 80 BF
0020: 68 FA 23 00 A4 38 35 EE 08 C8 53 80 06 05 0E 00
0030: 01 00 00 00 78 FA 23 00 94 EB 90 7C 00 0D DB BA
0040: 60 FA 23 00 08 39 35 00 64 3D 35 EE 5C 00 78 00
0050: 08 00 00 00 00 00 FF FF FF FF FF FF 00 00 00 00
0060: 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00
0070: 00 00 00 00 DC 58 FF FF FF FF 24 69 01 00 00 00
0080: A8 3B 35 EE 3B 00 00 00 06 05 0E 00 08 F9 6E 00
0090: 00 00 00 00 9C FB 23 00 3B 00 00 00 AA 94 D4 77
00A0: 1B 00 00 00 86 02 00 00 94 FB 23 00 23 00 00 00
00B0: FF 3F 00 00 38 39 35 EE 75 BC 4F 80 64 3D 35 EE
00C0: 7F 03 00 00 00 00 65 00 00 00 00 00 92 C8 4F 80
00D0: 64 3D 35 EE AA C7 4F 80 80 1F 00 00 50 00 00 00
00E0: 24 3D 35 EE 00 00 00 00 CA 00 00 00 C4 25 11 E1
00F0: A0 39 35 EE D6 4A 63 80 18 BA 4D E1 08 0C 3F E1
0100: C4 25 11 E1 01 3A 35 EE 98 39 35 EE 9F 39 35 EE
0110: 94 39 35 EE 90 3B 35 EE E8 67 2C E1 00 00 00 00
0120: CA 00 00 00 FF FF FF FF E8 25 11 E1 90 03 4E 00
0130: 04 3A 35 EE D3 64 62 80 18 BA 4D E1 08 0C 3F E1
0140: 00 00 00 00 60 FE 54 80 00 00 00 00 0D 09 62 80
0150: D4 39 35 EE 75 BC 4F 80 64 3D 35 EE 24 3A 35 EE
0160: 64 3D 35 EE F4 39 35 EE F2 C1 4F 80 64 3D 35 EE
0170: A0 EC 23 00 F0 3C 35 EE 84 EC 23 00 B8 E9 23 00
0180: 00 00 00 01 F4 3C 35 EE C2 F6 4F 80 64 3D 35 00
0190: 00 00 00 00 24 3A 35 EE 07 00 01 00 01 00 01 00
01A0: 64 3D 35 EE 00 00 00 00 CD F6 4F 80 00 00 00 00
01B0: 64 3D 35 EE 07 00 01 00 EE EA 91 7C 57 00 00 00
01C0: 05 EB 91 7C 05 00 00 C0 CC EC 23 00 00 00 00 00
01D0: E4 00 24 00 04 00 00 00 D4 00 24 00 C4 60 5D 80
01E0: 05 00 00 00 2F C0 00 00 F0 FE 75 BC D4 00 24 00
01F0: 00 00 00 00 10 00 00 00 00 00 00 00 5A 09 93 7C

On 2006-06-21 20:15:24 +0000, HyperHacker wrote:

Created attachment 140
Simple test case

This should create a 640x480 OpenGL window then close. When the bug occurrs, it creates the window then shows Windows' Application Error dialog.

On 2006-06-21 22:24:16 +0000, HyperHacker wrote:

This is interesting. Here's the results from SDL_GetVideoInfo:
HW Surface: 0
Window Manager: 1
Hardware blit: 0
With colour key: 0
With alpha: 0
Software blit: 0
With colour key: 0
With alpha: 0
Colour fill: 0
VRAM: 0 KB
Colour depth: 32 bits per pixel

This happens whether I have one monitor or both enabled, but despite this, SDL_SetVideoMode still succeeds when only one monitor is enabled.

On 2006-06-22 22:23:44 +0000, HyperHacker wrote:

I did some more poking, and this only seems to happen if the AGP card is set as primary in Windows. The PCI card is set as primary in the BIOS as it won't work otherwise. I swapped the monitors and made the PCI card primary in Windows, and it works. However it still crashes with the AGP card set to primary, so this is more of a workaround than a fix.

Also, I tried the test case using main() instead of WinMain(), and besides not printing anything to the console (I suspect a mistake on my part somewhere), it didn't make a difference.

On 2006-06-23 23:56:19 +0000, Sam Lantinga wrote:

Any reason you can't get a stack dump?
If you can't get a stack dump, can you add some debug print statements in the SDL video initialization code to see how far it gets?

On 2006-07-08 15:28:59 +0000, HyperHacker wrote:

(In reply to comment # 4)

Any reason you can't get a stack dump?
If you can't get a stack dump, can you add some debug print statements in the
SDL video initialization code to see how far it gets?

I might just be doing it wrong, but when I try to get a stack dump, it does so after the exception handler has executed, so the information is no good (it tells me what's happening in the "fatal error occurred" dialog, not what happened when the error occurred).
As for testing, I removed the second video card from my computer. If you absolutely can't find anyone else to test, I can put it back in for this purpose, but it'd be difficult. (I'm running both monitors from the AGP card now - it has a DVI port - and SDL is working fine with that setup.)

On 2006-11-27 05:03:15 +0000, HyperHacker wrote:

I think this might be related. If there are any translucent windows on the screen while an SDL+OpenGL program is running, they flicker quite a bit. If such a window is visible while the SDL_SetVideoMode() call is executing, the call may hang. How often it hangs seems random but can be up to 90% of the time in some cases.

On 2007-05-28 22:18:57 +0000, Ryan C. Gordon wrote:

Someone I was speaking with on IRC might have tracked this down separate from this bug report. (I've changed her name to "person" here, since I'm reposting the chatlog without permission). It sounds like the same issue.

I'm not prepared to work on this bug, but the info might make it easy for someone else to do so.

Today's pleasant discovery: SDL's win32 opengl support just won't work if you have three video cards in the machine.

Do not ask how I know this. Suffice it to say that I have an artist who really, really likes his multimonitor setup.

more specifically, it looks like the problem is (at least, according to gDebugger) when the win32 driver loads wglChoosePixelFormatARB() or wglGetPixelFormatAttribivARB(), it loads the extensions relative to gl context # 0

that GL context may not exist by the time those functions are actually called

so, AFAICT, when he loads SDL with his four monitor setup, the context created the second time apparently just ... blows up. I don't know if this is because it's on another monitor, or on another video card, or what. Probably the other video card, as SDL works fine on my multimonitor system

he has a GeForce FX 5200, a GeForce 4 MX, and a VIA/S3 Unichrome on-board.

the bad stuff happens in WIN_GL_SetupWindow() - look for:

if (this->gl_data->WGL_ARB_pixel_format)

ok, to be clear, you're calling SDL_SetVideoMode() a second time, or calling SDL_Quit() and then reinitting?

neither.

Call SDL_Init(SDL_INIT_VIDEO) and do the usual SDL_SetGraphicsMode() song and dance

and it blows up on the first call?

at some point this calls Init_WGL_ARB_Extensions()

which creates a new GL context, loads driver pointers, then deletes that context in the same procedure

oh

the blowup is after you set the video mode, for the first time.

it doesn't even get off the ground here.

--ryan.

On 2007-06-02 13:58:55 +0000, Ryan C. Gordon wrote:

Bumping a bunch of bugs to Priority 1 for consideration for the 1.2.12 release.

--ryan.

On 2007-07-05 23:30:55 +0000, Sam Lantinga wrote:

I'll look at this. I may be able to throw two video cards into a system and debug it. I'm not sure how to choose a pixel format to create a context if I have to create a context to get the function pointers to choose the pixel format. :)

Does anyone have an example that works correctly in this configuration?

On 2007-07-09 23:23:58 +0000, Sam Lantinga wrote:

I tested this extensivey with a Radeon 9200 and Matrox Millennium II, on Windows XP SP2 and had no problems.

I tried both cards as primary in a variety of bit depths and resolutions, and when the testgl application was started on the Matrox it would run using the GDI driver, and when started on the Radeon it would run using the accelerated ATI driver.

Are you testing with the latest drivers? Does the bug still occur with the SDL subversion snapshot?
http://www.libsdl.org/tmp/SDL-1.2.12.zip
Let me know if you need a precompiled DLL.

Are you able to debug the problem at all? If not, and you're willing to send the problematic video card combination to me, I'll see if I can reproduce the configuration and then send them back.

On 2007-07-10 23:15:16 +0000, Sam Lantinga wrote:

Okay, I think I figured out how to fix this. I changed the SDL code so that it doesn't use the wglChoosePixelFormatARB() function after the temporary context has been deleted.

Can you try this and let me know if it works? http://www.libsdl.org/tmp/SDL.dll

On 2007-08-19 20:59:23 +0000, Ryan C. Gordon wrote:

My IRC contact confirmed this is working now.

--ryan.

On 2007-08-19 21:01:56 +0000, HyperHacker wrote:

(In reply to comment # 6)

I think this might be related. If there are any translucent windows on the
screen while an SDL+OpenGL program is running, they flicker quite a bit. If
such a window is visible while the SDL_SetVideoMode() call is executing, the
call may hang. How often it hangs seems random but can be up to 90% of the time
in some cases.

For the record, these problems were caused by crappy video drivers. A new video card fixed them both.