Project

General

Profile

Actions

Emulator Issues #2403

closed

Probable 'System Specific' OpenGL crash

Added by shadoweffex almost 15 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What steps will reproduce the problem?

  1. Have MSAA enabled to any value.
  2. Run any game in the list.
  3. Usually, Dolphin crashes when you load a second random game, but
    because of the randomness of this bug, it could take a few tries.

What is the expected output? What do you see instead?
I expect Dolphin to continue running, even when hitting a critical video
bug or similar. Dolphin either freezes, hangs or crashes when this bug is
hit.

What version of the product are you using? On what operating system?
Dolphin 2.0 RC1 and SVN R5172 on Windows XP 32bit (I have no access to
x64, at the moment). I’m using an ASUS NVIDIA GTX 285 with the 196.21
driver set (from the NVIDIA website). All clean installations.

Please provide any additional information below.
Now here is when it gets tricky. I have observed this bug since almost day
1 so I once thought it was simply my system acting up, but after a few
formats and hardware changes, I believe it could be a combination of
hardware or software settings causing this bug to happen. I can faithfully
reproduce this bug (crash) when enabling MSAA. No other setting has been
causing trouble including when MSAA is disabled.

After some further investigation, I discovered that using XFB prevents
Dolphin from crashing with any of the other OpenGL settings enabled or
used. With the help of BhaaL and ector I was able to go on the route of
debugging Dolphin with Visual C++ 2008 Express Edition. It seems a couple
of addresses are hit when the crash occurs. Those most dominant one is:
0x0edb59c0

Original message:
Unhandled exception at 0x0edb59c0 in DolphinDF.exe: 0xC0000005: Access
violation reading location 0x00000038.

The question is if this'll help the developers, as it could be that more
locations are hit or is simply too random. The file ‘nvoglnt.dll’ seems to
be used in the process and when I look in the source code, the file
FramebufferManager.cpp is being used at the time of the crash. This
concerns the function ‘glBlitFramebufferEXT’ on line 405. If I comment
that out, and run Dolphin via the debug function, I get a black screen
(obvious, probably) but I can load game after game just fine. Though,
sometimes I do hit another crash (either with loading or using the Stop
button) but I guess I'm hitting another bug there so I'm leaving it out of
the scope of this bug report.

This bug is a real show stopper for me and I've been using Direct3D9 plug-
in at times as a workaround. It seems I don't encounter any bug of this
nature with that plug-in. Even toggling Dual Core usage doesn't seem to
help.

If more people recognize this, please don't hesitate to jump in.

Actions #1

Updated by shadoweffex almost 15 years ago

Many people cannot reproduce this bug, so it will be difficult to track down root
cause.

Actions #2

Updated by BhaaL almost 15 years ago

Some notes on what I found on this:

  • Affects only NVidia OGL drivers (at least in the reported way); ATI seems to be
    fine (I also get exceptions in there with ATI when running in the debugger, but they
    seem to be handled or otherwise ignore when running without debugger).
  • It seems to be caused by GLEW extensions (here: glBlitFramebufferEXT) being used in
    a multithreaded environment, without a (or with a wrong) call to wglMakeCurrent (see
    http://www.devmaster.net/forums/showthread.php?t=12627 for information).

His observations were made in FramebufferManager::copyToVirtualXFB, on the path where
MSAA is enabled.

I looked at the OGL code and pretty much found MakeCurrent calls in the places where
I'd have put them if they were missing; so I'm a bit out of options. Would be nice if
someone with more OGL knowledge than me could look at it.

Actions #3

Updated by shadoweffex almost 15 years ago

Thanks j4ck fr0st, here's me hoping more developers can take a look at this.
Just figured out that the new -Use XFB- also causes Dolphin to freeze in the same
manner. Using -Real XFB- works fine, though, but produces a short green/static screen
at the start but I consider this minor.

I believe zerofrog initially wrote the OpenGL plugin, so he might know more about this.

Actions #4

Updated by shadoweffex over 14 years ago

To be honest, I wasn't really expected this to be fixed soon or at all. I have now
jumped on Windows 7 x64 and am not experiencing this anymore. However, the graphics
tend to partly disappear or show weird colors after a couple of game loads.

I'm not sure if this issue will be fixed, but if desired, this issue may be closed.

Actions #5

Updated by BhaaL over 14 years ago

  • Status changed from New to Invalid

Closing, since we cant reproduce this anyways.

Actions

Also available in: Atom PDF