Alert Window - Is it safe?

#1

I’ve got a access violation, while opening a alert window (on Mac OS)
But it was not repeatable. It happened with a release build with no debug symbols. So i checked the code for potential problems.

When opening the window with the static function showMessageBox, it creates a struct (AlertWindowInfo) and calls callFunctionOnMessageThread.
When the thread is not the MessageThread it sends a message.
It is possible the struct is deleted before the show() function is called?

[code]void AlertWindow::showMessageBox (AlertIconType iconType,
const String& title,
const String& message,
const String& buttonText)
{
AlertWindowInfo info;
info.title = title;
info.message = message;
info.button1 = buttonText.isEmpty() ? TRANS(“ok”) : buttonText;
info.iconType = iconType;
info.numButtons = 1;

info.run();

[/code]

[code]struct AlertWindowInfo
{
String title, message, button1, button2, button3;
AlertWindow::AlertIconType iconType;
int numButtons;

int run() const
{
    return (int) (pointer_sized_int)
            MessageManager::getInstance()->callFunctionOnMessageThread (showCallback, (void*) this);
}[/code]
#2

i forgot the stack trace

[code]Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xf5000001

Thread 0 Crashed:
0 libobjc.A.dylib 0x90a594c7 objc_msgSend + 23
1 com.apple.CoreFoundation 0x90820799 __CFDictionaryFindBuckets1b + 88
2 com.apple.CoreFoundation 0x90820726 CFDictionaryGetValue + 201
3 com.apple.HIToolbox 0x92de9c03 HIObjectClass::Lookup(__CFString const*, unsigned char) + 97
4 com.apple.HIToolbox 0x92de9a69 HIObject::Create(__CFString const*, OpaqueEventRef*, HIObject**) + 35
5 com.apple.HIToolbox 0x92de99ea HIObjectCreate + 76
6 com.apple.HIToolbox 0x92dfdb0a NewWindowCommon(WindowData**, unsigned long, unsigned long, WindowDefSpec const*, Rect const*, unsigned char const*, unsigned char, OpaqueWindowPtr*, long, void*, unsigned short*, bool) + 1574
7 com.apple.HIToolbox 0x92dfd3d0 CreateNewWindowInternal(WindowDefSpec const*, unsigned long, unsigned long, Rect const*, OpaqueWindowPtr**) + 328
8 com.apple.HIToolbox 0x92e9d61e CreateCustomWindow + 134
9 com.company.pluginname 0x21f75cdc 0x21d6c000 + 2137308
10 com.company.pluginname 0x21f769a5 0x21d6c000 + 2140581
11 com.company.pluginname 0x21de2962 PluginEntry + 427520
12 com.company.pluginname 0x21e0b67c PluginEntry + 594714
13 com.company.pluginname 0x21e87bfd PluginEntry + 1104027
14 com.company.pluginname 0x21e07198 PluginEntry + 577078
15 com.company.pluginname 0x21dccd0a PluginEntry + 338344
16 com.company.pluginname 0x21de95c8 PluginEntry + 455270
17 com.company.pluginname 0x21de9788 PluginEntry + 455718
18 com.company.pluginname 0x21de9a94 PluginEntry + 456498
19 com.company.pluginname 0x21e080b3 PluginEntry + 580945
20 com.company.pluginname 0x21e89016 PluginEntry + 1109172
21 com.company.pluginname 0x21f7712c 0x21d6c000 + 2142508
22 com.company.pluginname 0x21f7a6df 0x21d6c000 + 2156255
23 com.company.pluginname 0x21f7a7b9 0x21d6c000 + 2156473
24 com.apple.HIToolbox 0x92dee4d7 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093
25 com.apple.HIToolbox 0x92dedb7c SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
26 com.apple.HIToolbox 0x92df4f7c SendEventToEventTarget + 56
27 com.apple.HIToolbox 0x92df540f ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1169
28 com.apple.HIToolbox 0x92dee88e DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2044
29 com.apple.HIToolbox 0x92dedb7c SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
30 com.apple.HIToolbox 0x92df4f7c SendEventToEventTarget + 56
31 com.apple.HIToolbox 0x92e38eb3 ToolboxEventDispatcher + 81
32 com.apple.HIToolbox 0x92e378cb RunApplicationEventLoop + 165
33 com.ableton.live 0x00087b5f 0x1000 + 551775
34 com.ableton.live 0x000028da 0x1000 + 6362
35 com.ableton.live 0x000027f5 0x1000 + 6133[/code][/code]

#3

No… I don’t think the stuct could disappear too early. It has to be there until the member function has finished running.

Strange stack trace, it’s crashing deep in apple code, and I can’t see anything dangerous that could be getting passed to the CreateCustomWindow method. There’s a customWindowClass object used, but that all looks fine to me…

#4

ahh,now i understand, the method returns not until the callback has processed the message. ( i previously thought it happens asynchronous )

#5