Opened 13 years ago

Last modified 13 years ago

#9749 accepted defect

Chandler's Graphics Context based month view crashes on OS X 1/10th of the time

Reported by: jeffrey Owned by: csomor
Priority: normal Milestone:
Component: old wxOSX/Carbon port Version:
Keywords: Cc:
Blocked By: Blocking:
Patch: no


To reproduce:

  1. Download
  2. Start up Chandler
  3. Select the Calendar
  4. Choose Month View (by clicking on the month's name)
  5. Choose Week View (by clicking the left hand side where it says "Week 25" or whatever a recent week is

Repeat 4. and 5. a dozen times, and at some point you'll get a segfault on OS X.

I'm not sure what's going wrong, but my guess is something's going wrong with Graphics Context on the Mac.

Change History (9)

comment:1 Changed 13 years ago by vadz

  • Status changed from new to infoneeded_new

Would it be possible to get a stack trace for the crash?


comment:2 Changed 13 years ago by jeffrey

  • Status changed from infoneeded_new to new

Here's a stack trace. Looks like something's triggering drag-n-drop. I've noticed that dragging onto various widgets seems to crash Chandler on OS X, but last time I checked not on Windows, so this may be the same issue.

What I'm doing *shouldn't* be triggering drag'n'drop, but I haven't succeeded at building a Python with symbols on Leopard yet, so I'm not quite sure what's going on in Chandler's Python code yet.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x7461446e
0x0238172f in wxNodeBase::GetData (this=0x74614466) at list.h:475
475 void *GetData() const { return m_data; }
(gdb) bt
#0 0x0238172f in wxNodeBase::GetData (this=0x74614466) at list.h:475
#1 0x0257ed51 in wxListBase::Find (this=0x1eece1a0, object=0x1d206a60) at ../src/common/list.cpp:347
#2 0x024222c8 in wxWindowList::Find (this=0x1eece1a0, object=0x1d206a60) at window.h:111
#3 0x02670d97 in wxMacTopLevelMouseEventHandler (handler=0xbfffd950, event=0x1f0da420, data=0xd20a00) at ../src/mac/carbon/toplevel.cpp:601
#4 0x02671ca5 in wxMacTopLevelEventHandler (handler=0xbfffd950, event=0x1f0da420, data=0xd20a00) at ../src/mac/carbon/toplevel.cpp:844
#5 0x94516763 in DispatchEventToHandlers ()
#6 0x94515b9d in SendEventToEventTargetInternal ()
#7 0x945324ee in SendEventToEventTarget ()
#8 0x94544b90 in ToolboxEventDispatcherHandler ()
#9 0x94516b1c in DispatchEventToHandlers ()
#10 0x94515b9d in SendEventToEventTargetInternal ()
#11 0x945324ee in SendEventToEventTarget ()
#12 0x02601663 in wxApp::MacHandleOneEvent (this=0xb5f6e60, evr=0x1f0da420) at ../src/mac/carbon/app.cpp:1229
#13 0x0260175e in wxApp::MacDoOneEvent (this=0xb5f6e60) at ../src/mac/carbon/app.cpp:1197
#14 0x026200be in wxEventLoop::Dispatch (this=0xb5a0850) at ../src/mac/carbon/evtloop.cpp:107
#15 0x026d399a in wxEventLoopManual::Run (this=0xb5a0850) at ../src/common/evtloopcmn.cpp:122
#16 0x026a7b03 in wxAppBase::MainLoop (this=0xb5f6e60) at ../src/common/appcmn.cpp:314
#17 0x02377055 in wxPyApp::MainLoop (this=0xb5f6e60) at src/helpers.cpp:184
#18 0x023cbe45 in _wrap_PyApp_MainLoop (args=0x1f9b7b0) at src/mac/_core_wrap.cpp:31158
#19 0x0011fd3d in PyObject_Call ()
#20 0x0018dfb8 in PyEval_EvalFrameEx ()
#21 0x0018f45b in PyEval_EvalCodeEx ()
#22 0x00139c27 in PyFunction_SetClosure ()
#23 0x0011fd3d in PyObject_Call ()
#24 0x001285f8 in PyMethod_New ()
#25 0x0011fd3d in PyObject_Call ()
#26 0x0018db1a in PyEval_EvalFrameEx ()
#27 0x0018d9e8 in PyEval_EvalFrameEx ()
#28 0x0018f45b in PyEval_EvalCodeEx ()
#29 0x0018da85 in PyEval_EvalFrameEx ()
#30 0x0018d9e8 in PyEval_EvalFrameEx ()
#31 0x0018f45b in PyEval_EvalCodeEx ()
#32 0x0018f548 in PyEval_EvalCode ()
#33 0x001a69ec in PyErr_Display ()
#34 0x001a7016 in PyRun_FileExFlags ()
#35 0x001a8982 in PyRun_SimpleFileExFlags ()
#36 0x001b3c03 in Py_Main ()
#37 0x00001fca in ?? ()

comment:3 Changed 13 years ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

Hi Jeffrey

why do you think it is triggering a dnd ? (I've opened a ticket for the dnd problem at #9748 btw, to collect evidences that might help me to reproduce it)

which wx version is this based on ?



comment:4 Changed 13 years ago by csomor

Hi Jeffrey

I don't seem to be able to reproduce it, but of course I have no full chandler calendar so this doesn't really count, I have a suspicion based on the stacktrace though, that we have some intermediate state of the objects creation/destruction

does it also happen if you wait before clicking abain until everything has been redrawn + some 10 seconds, just to make sure the destructors scheduled for idle time are also completed



comment:5 Changed 13 years ago by jeffrey

Hi Stefan,

We're using (not sure whose repository the r212 refers to, though).

I can reproduce this from a nearly empty calendar if I create 3-4 events (by double-clicking on different days), but it occasionally takes me a few (tedious) minutes. Sorry, I thought this was more reliable. It always happens eventually...

I associated GetData with DnD, but actually, I don't think that's what the code's doing there.

I just noticed that I mainly see this after I updated the version of wx Chandler is using, when I use a slightly older version (the one in the download I pointed you to) it takes 100's of clicks to segfault. So, you might try with:

if you can't reproduce the problem.

The stack trace (this time from Apple's report, not gdb) I'm getting now looks a little different:

Thread 0 Crashed:
0 libwx_macu-2.8.0.dylib 0x01df49d0 wxListBase::Find(void const*) const + 16
1 libwx_macu-2.8.0.dylib 0x01ecc4d3 wxMacTopLevelMouseEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1379
2 libwx_macu-2.8.0.dylib 0x01ecccd6 wxMacTopLevelEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1318
3 0x94516763 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1181
4 0x94515b9d SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 405
5 0x945324ee SendEventToEventTarget + 52
6 0x94544b90 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 1208
7 0x94516b1c DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2134
8 0x94515b9d SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 405
9 0x945324ee SendEventToEventTarget + 52
10 libwx_macu-2.8.0.dylib 0x01e65c36 wxApp::MacHandleOneEvent(void*) + 38
11 libwx_macu-2.8.0.dylib 0x01e6650a wxApp::MacDoOneEvent() + 170
12 libwx_macu-2.8.0.dylib 0x01e80dd3 wxEventLoop::Dispatch() + 35
13 libwx_macu-2.8.0.dylib 0x01f2de6f wxEventLoopManual::Run() + 159
14 libwx_macu-2.8.0.dylib 0x01f050f3 wxAppBase::MainLoop() + 83
15 0x01c09b2d wxPyApp::MainLoop() + 61
16 0x01c5bbd9 _wrap_PyApp_MainLoop + 89
17 org.python.python 0x0011fd3d PyObject_Call + 50
18 org.python.python 0x0018dfb8 PyEval_EvalFrameEx + 19086
19 org.python.python 0x0018f45b PyEval_EvalCodeEx + 1638
20 org.python.python 0x00139c27 PyFunction_SetClosure + 2646
21 org.python.python 0x0011fd3d PyObject_Call + 50
22 org.python.python 0x001285f8 PyMethod_New + 2457
23 org.python.python 0x0011fd3d PyObject_Call + 50
24 org.python.python 0x0018db1a PyEval_EvalFrameEx + 17904
25 org.python.python 0x0018d9e8 PyEval_EvalFrameEx + 17598
26 org.python.python 0x0018f45b PyEval_EvalCodeEx + 1638
27 org.python.python 0x0018da85 PyEval_EvalFrameEx + 17755
28 org.python.python 0x0018d9e8 PyEval_EvalFrameEx + 17598
29 org.python.python 0x0018f45b PyEval_EvalCodeEx + 1638
30 org.python.python 0x0018f548 PyEval_EvalCode + 87
31 org.python.python 0x001a69ec PyErr_Display + 1896
32 org.python.python 0x001a7016 PyRun_FileExFlags + 135
33 org.python.python 0x001a8982 PyRun_SimpleFileExFlags + 421
34 org.python.python 0x001b3c03 Py_Main + 3095
35 org.python.pythonapp 0x00001fca 0x1000 + 4042

comment:6 Changed 13 years ago by csomor

Hi Jeffrey

I couldn't reproduce the crash using your pattern first, then I added some double clicks to the mix and I started crashing. Unfortunately the download link to the debug version is producing an empty dmg, so gdb cannot help me with local vars, is producing the debug dmg having some serious problems, or could you bake me one ?



comment:7 Changed 13 years ago by jeffrey

Hmm, odd, not sure what went wrong with the debug builds there. The debug dmg seems to be working fine for the latest build, though:

comment:8 Changed 13 years ago by csomor

Hi Jeffrey

after staring at the few lines in the mouse handler I've got another idea :

what exactely are you doing in that mouse-down handler ? destroying the parent window ? this would explain what happens, since this would mean that the stored pointer isn't valid anymore.



comment:9 Changed 13 years ago by csomor

HI Jeffrey

in case you are destroing both the window that is getting the event and its parent at that moment you could try changing the following :

in src/mac/carbon/toplevel.cpp, line 600


if ((currentMouseWindowParent != NULL) &&
    (currentMouseWindowParent->GetChildren().Find(currentMouseWindow) == NULL))


if ( g_MacLastWindow == NULL )

this is set to NULL exactely if the window that is getting the event is destroyed



Note: See TracTickets for help on using tickets.