Project

General

Profile

Actions

Emulator Issues #704

closed

Crash loading plugins on Mac OS X

Added by fprimex about 15 years ago.

Status:
Fixed
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. Run Dolphin.app
  2. Click on any of the plugin config buttons (i.e. audio)
  3. Dismiss the error stating that the .dylib cannot be found (despite it
    existing in the path specified in the message)
  4. The program will crash after the dialog is dismissed

What is the expected output? What do you see instead?
I expect to get the audio config dialog, but failing that, would expect the
system to not crash if it isn't finding it correctly.

What version of the product are you using? On what operating system?
SVN r2540

Please provide any additional information below.
This incident was reported in the forums. Here is the last forum post:

Interestingly, the program did not crash the first time I tried this in the
debugger. In my experience this means that there is a variable that was not
initialized to a default value, and depending on the compiler/OS, either
gets a sane default value or trash. However, it looks like m_DllConfig is
getting set to NULL in the CPlugin constructor, then set again using
m_hInstLib.Get. Maybe that .Get is returning garbage:

Download source Code
(gdb) print m_DllConfig
Cannot access memory at address 0x18

I do get an error message that pops up and then gets dismissed - that of
saying "Panic, can't open this dynlib plugin, it's missing" when in fact
the file is there, but I think the program state is corrupted much earlier
in execution, before the dialog.

Full backtrace:

Download source Code
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000018
0x00102939 in Common::CPlugin::Config (this=0x0, _hwnd=0x112ec80) at
Source/Core/Common/Src/Plugin.cpp:94
94 if (m_DllConfig != NULL)
(gdb) bt
#0 0x00102939 in Common::CPlugin::Config (this=0x0, _hwnd=0x112ec80) at
Source/Core/Common/Src/Plugin.cpp:94
#1 0x00068790 in CPluginManager::OpenConfig (this=0x181680,
_Parent=0x112ec80, _rFilename=0x11434dc
"/Users/brent/code/dolphin-emu/Binary/Darwin-i386/Dolphin.app/Contents/PlugIns",
Type=PLUGIN_TYPE_DSP) at Source/Core/Core/Src/PluginManager.cpp:533
#2 0x00016605 in CFrame::OnPluginDSP (this=0x1824600) at
Source/Core/DolphinWX/Src/FrameTools.cpp:629
#3 0x00873ac3 in wxEvtHandler::ProcessEventIfMatches ()
#4 0x00873c3f in wxEventHashTable::HandleEvent ()
#5 0x008744ef in wxEvtHandler::ProcessEvent ()
#6 0x009ba502 in wxWindowBase::TryParent ()
#7 0x0087449c in wxEvtHandler::ProcessEvent ()
#8 0x009b228d in wxToolBarBase::OnLeftClick ()
#9 0x008fb0e9 in wxMacToolBarToolEventHandler ()
#10 0x94d6a143 in DispatchEventToHandlers ()
#11 0x94d6957d in SendEventToEventTargetInternal ()
#12 0x94d85ed2 in SendEventToEventTarget ()
#13 0x94ddfb95 in SendControlHit ()
#14 0x94ddfa15 in HIView::NotifyControlHit ()
#15 0x94e49934 in HIView::ClickInternal ()
#16 0x94ec7b35 in HandleControlClick ()
#17 0x00900256 in wxMacTopLevelMouseEventHandler ()
#18 0x00900846 in wxMacTopLevelEventHandler ()
#19 0x94d6a143 in DispatchEventToHandlers ()
#20 0x94d6957d in SendEventToEventTargetInternal ()
#21 0x94d85ed2 in SendEventToEventTarget ()
#22 0x94d980a8 in ToolboxEventDispatcherHandler ()
#23 0x94d6a4fc in DispatchEventToHandlers ()
#24 0x94d6957d in SendEventToEventTargetInternal ()
#25 0x94d85ed2 in SendEventToEventTarget ()
#26 0x00899b56 in wxApp::MacHandleOneEvent ()
#27 0x00899c2f in wxApp::MacDoOneEvent ()
#28 0x008b5273 in wxEventLoop::Dispatch ()
#29 0x009627ef in wxEventLoopManual::Run ()
#30 0x009397b3 in wxAppBase::MainLoop ()
#31 0x0081d5fa in wxEntry ()
#32 0x000404b8 in main (argc=1, argv=0xbffff5dc) at
Source/Core/DolphinWX/Src/Main.cpp:57
(gdb)

Actions #1

Updated by marcus about 15 years ago

Why r2540? You should get the latest svn (who knows, maybe it's fixed there?)
Anyway,
"Reason: KERN_PROTECTION_FAILURE at address: 0x00000018"
seems to say that your folder is protected/hidden? Try looking at that. Don't know
why
GetVideo()->Config((HWND)_Parent) worked when GetDSP()->Config((HWND)_Parent) didn't.

Actions #2

Updated by fprimex about 15 years ago

That's weird. I did this checkout earlier this week and that was the revision I got.
I just did an svn up, received r2565, and recompiled.

The problem persists with this revision. I checked the file permissions of
Dolphin.app/Contents/PlugIns/* - I have read and write access to all of these files
and directories. All of the directories have the execute permission as well, and I
checked to ensure that none of the files or directories had the OS X 'locked'
property set. I don't see how they'd be protected or hidden, unless there is some
implication given they exist inside an application bundle.

The graphics config does the same thing:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000018
0x000f831d in Common::CPlugin::Config (this=0x0, _hwnd=0x112ec80) at
Source/Core/Common/Src/Plugin.cpp:94
94 if (m_DllConfig != NULL)
(gdb) bt
#0 0x000f831d in Common::CPlugin::Config (this=0x0, _hwnd=0x112ec80) at
Source/Core/Common/Src/Plugin.cpp:94
#1 0x00067dfa in CPluginManager::OpenConfig (this=0x172ba0, _Parent=0x112ec80,
_rFilename=0x1142c5c
"/Users/brent/code/dolphin-emu/Binary/Darwin-i386/Dolphin.app/Contents/PlugIns/libPlugin_VideoOGL.dylib",
Type=PLUGIN_TYPE_VIDEO) at Source/Core/Core/Src/PluginManager.cpp:530
#2 0x00015d4d in CFrame::OnPluginGFX (this=0x1824600) at
Source/Core/DolphinWX/Src/FrameTools.cpp:619
#3 0x00873ac3 in wxEvtHandler::ProcessEventIfMatches ()
#4 0x00873c3f in wxEventHashTable::HandleEvent ()
#5 0x008744ef in wxEvtHandler::ProcessEvent ()
#6 0x009ba502 in wxWindowBase::TryParent ()
#7 0x0087449c in wxEvtHandler::ProcessEvent ()
#8 0x009b228d in wxToolBarBase::OnLeftClick ()
#9 0x008fb0e9 in wxMacToolBarToolEventHandler ()
#10 0x94d6a143 in DispatchEventToHandlers ()
#11 0x94d6957d in SendEventToEventTargetInternal ()
#12 0x94d85ed2 in SendEventToEventTarget ()
#13 0x94ddfb95 in SendControlHit ()
#14 0x94ddfa15 in HIView::NotifyControlHit ()
#15 0x94e49934 in HIView::ClickInternal ()
#16 0x94ec7b35 in HandleControlClick ()
#17 0x00900256 in wxMacTopLevelMouseEventHandler ()
#18 0x00900846 in wxMacTopLevelEventHandler ()
#19 0x94d6a143 in DispatchEventToHandlers ()
#20 0x94d6957d in SendEventToEventTargetInternal ()
#21 0x94d85ed2 in SendEventToEventTarget ()
#22 0x94d980a8 in ToolboxEventDispatcherHandler ()
#23 0x94d6a4fc in DispatchEventToHandlers ()
#24 0x94d6957d in SendEventToEventTargetInternal ()
#25 0x94d85ed2 in SendEventToEventTarget ()
#26 0x00899b56 in wxApp::MacHandleOneEvent ()
#27 0x00899c2f in wxApp::MacDoOneEvent ()
#28 0x008b5273 in wxEventLoop::Dispatch ()
#29 0x009627ef in wxEventLoopManual::Run ()
#30 0x009397b3 in wxAppBase::MainLoop ()
#31 0x0081d5fa in wxEntry ()
#32 0x0003fdc0 in main (argc=1, argv=0xbffff5e4) at Source/Core/DolphinWX/Src/Main.cpp:57
(gdb) print m_DllConfig
Cannot access memory at address 0x18
(gdb)

Actions #3

Updated by marcus about 15 years ago

How about finding a memory test program and running it? Perhaps some of your RAM is
bad?

Actions #4

Updated by fprimex about 15 years ago

Ran Rember (a front end to memtest http://www.kelleycomputing.net/rember/) and all
tests passed.

Actions #5

Updated by marcus about 15 years ago

Well, it's got me stumped. I'm new though, so hrydgard can probably help you more.

Actions #6

Updated by hrydgard about 15 years ago

Me? I don't do OSX :P

Actions #7

Updated by marcus about 15 years ago

oh...well, neither do I, is there any dev that does?

Actions #8

Updated by XTra.KrazzY about 15 years ago

Yes, tmator.

Actions #9

Updated by jricks92 about 15 years ago

just tried to compile r2599 but it doesn't work. Let me know if i need to post the errors

Actions #10

Updated by marcus about 15 years ago

That might help, if they aren't identical to ones already posted.

Actions #11

Updated by bushing about 15 years ago

I haven't tried to reproduce this yet, but just from looking at the backtrace:

0x00102939 in Common::CPlugin::Config (this=0x0, _hwnd=0x112ec80) at
Source/Core/Common/Src/Plugin.cpp:94

Doesn't the fact that this == NULL mean that the object hasn't been initialized? This doesn't give the root cause
of the problem, but we should add some error checking code. I'm going to venture to guess that the constructor
hasn't been called?

Actions #12

Updated by Sonicadvance1 about 15 years ago

I had fixed this problem in my own custom build for OSX. but it wasn't a very good
way to do it. I'm looking in to why it does it now

Actions #13

Updated by Sonicadvance1 about 15 years ago

  • Status changed from New to Fixed

Should be fixed in rev 3074. WX may still crash it sometimes.

Actions

Also available in: Atom PDF