Emulator Issues #2871
closed
OSX Crash when opening configuration
Added by BhaaL almost 14 years ago.
Relates to performance:
No
Relates to maintainability:
No
Description
What steps will reproduce the problem?
- Run Dolphin.
- Open one of the Configuration Windows by clicking "Graphics" (for example).
- Null-pointer in wxWindow::DoGetPosition.
32-bit or 64-bit and any other build parameters?
i386, also observed on x86_64
OS version and versions of tools/libraries used?
OSX 10.6.4, gcc 4.2.1 (Xcode 3.2.2), wxWidgets SVN r64594 (also with r63470)
GDB:
[...]
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x00ad0c55 in wxWindow::DoGetPosition ()
(gdb) bt
#0 0x00ad0c55 in wxWindow::DoGetPosition ()
#1 0x00bfe717 in wxDisplayFactory::GetFromWindow ()
#2 0x00bfe8ca in wxDisplay::GetFromWindow ()
#3 0x00caf6d8 in wxTopLevelWindowBase::DoCentre ()
#4 0x0c9585cd in GFXConfigDialogOGL::CreateGUIControls ()
Does this also happen for you two? cinoI on IRC reported this to me and I can reproduce it, but according to the wx source it shouldnt happen (nothing in there could be null that isnt checked). Hence I don't think we can simply report it to wx and call it a day, as it might be our own fault there.
Btw: crashes on Graphics and DSP for me, but NOT on Config, GCPad or Wiimote.
I don't get such crashes with r63470 but I do get various spurious crashes in wx (can't recall if DoGetPosition came up) with never versions than r63470.
Like you I am not at all ready to blame wx for those either..
Hm, correction on that part (i guess). ionic wasn't using 63470 by that time, and I just checked their revision log for the osx window. Apparently, nothing changed in there between 63470 and HEAD, so it might be something else causing this.
I just re-tested with WxWidgets SVN r63470, it does definitely NOT crash with this revision.
At this point, what do you suggest? Bisecting the WxWidgets SVN repo?
I think the problem is in plugins' GetParentedWxWindow() functions, which on OS X returns just a new wxWindow. When that is used as the parent window for plugin's config dialog, doGetPosition crashes.
Here's a patch that fixes this.
So, you basically replaced the HWND with void* and passed the whole object in, rather than its handle?
It's usually a bad idea passing around non-POD stuff to dynamically loaded libraries, which is why we used the path of just passing the handle. Windows has SetHWND for that, but I don't know of a similar thing for non-win32.
Well, the patch was basically meant to be just a quick solution to make the config dialogs work, but I'd still prefer a proper solution. Just wondering why nobody has done anything to this win32-only stuff?
The problem is the lack of (knowledge about) non-win32 stuff to use for such cases.
Theres a section about using wx from within libraries, but not a single word about passing around handles. So, infact, what we have is just guessing that seemed to work in most cases (except OSX, as we can see now).
I can't think of another way to do this properly, and I'd like to avoid going that way of passing objects around (especially with that wx dtor/Destroy/Cleanup-whatever-queue-thing in place).
- Status changed from New to Fixed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by