How to debug segmentation fault on MacOS

Hello, I am the newbie on wxPython.

When I try to run application implemented using wxPython, it is crashed on MacOS.

On the other platform CentOS7, Ubuntu, Windows, there is no crash.

The root cause is wx.auiManager(), When I call SetManagedWindow(panel), it crashes.

I have two questions.

  • What causes this crash, it there different rule that I may miss?
  • How cloud I debug where is the main point that make it crash?

To debug, I download source code archive, install gdb and codesigned on my MacOS, I installed wxPython by pip install -e . on my extracted directory. then start gdb and run it run app.py

It makes another error

Traceback (most recent call last):
  File "/Users/universehan/workspace/alsemy/reproduce-wxcrash/main.py", line 1, in <module>
    import wx
  File "/Users/universehan/opensource/wxPython-4.1.1/wx/__init__.py", line 17, in <module>
    from wx.core import *
  File "/Users/universehan/opensource/wxPython-4.1.1/wx/core.py", line 12, in <module>
    from ._core import *
ModuleNotFoundError: No module named 'wx._core'

The simple source code which reproduce this problem is


class EmptyPanel(wx.Panel):
    def __init__(self, parent):
        wx.Panel.__init__(self, parent)
        self.mgr = aui.AuiManager()
        self.mgr.SetManagedWindow(self)


class SimpleChildFrame(aui.AuiMDIChildFrame):
    def __init__(self, parent):
        aui.AuiMDIChildFrame.__init__(self, parent, -1, title="Test")
        self.p = EmptyPanel(self)

class TopFrame(aui.AuiMDIParentFrame):
    def __init__(self, parent):
        aui.AuiMDIParentFrame.__init__(self, parent, -1, "Test Application", size=(1500, 800),
                                       style=wx.DEFAULT_FRAME_STYLE)

        child = SimpleChildFrame(self)

if __name__ == '__main__':
    app = wx.App()

    frm = TopFrame(None)
    frm.Show()
    app.MainLoop()

Thank you.

That means you want to use the source code of wxPython. But it must be built. Why don’t you install normally from pip?
sudo -H pip install wxPython # Note I usually use sudo, you may have other preferences.

Hello, Thank you for your time to answer for my question.

Yes, As you said I missed to build first. The reason why I did not use normal install pip install wxPython is that it does not contains debug info which gave me the ??? for where the segmentation fault was happend. I expected better information about where the segmentation fault happed.

Now I tried to build by python build.by --debug and pip install -e .

It seems solved the problem about wx._core. It made me to be able to debug using lldb.

I succeed to get stack trace and it’s function name

(lldb) r main.py 
Process 92326 launched: '/usr/local/bin/python3' (x86_64)
Process 92326 stopped
* thread #2, stop reason = exec
    frame #0: 0x000000010000e000 dyld`_dyld_start
dyld`_dyld_start:
->  0x10000e000 <+0>: popq   %rdi
    0x10000e001 <+1>: pushq  $0x0
    0x10000e003 <+3>: movq   %rsp, %rbp
    0x10000e006 <+6>: andq   $-0x10, %rsp
Target 0: (Python) stopped.
(lldb) c
Process 92326 resuming
Process 92326 stopped
* thread #2, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001041b011b libwx_osx_cocoau_core-3.1.5.0.0.dylib`wxNonOwnedWindow::CanSetTransparent() + 11
libwx_osx_cocoau_core-3.1.5.0.0.dylib`wxNonOwnedWindow::CanSetTransparent:
->  0x1041b011b <+11>: movq   (%rdi), %rax
    0x1041b011e <+14>: popq   %rbp
    0x1041b011f <+15>: jmpq   *0x90(%rax)
    0x1041b0125 <+21>: nopw   %cs:(%rax,%rax)
Target 0: (Python) stopped.
(lldb) bt
* thread #2, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001041b011b libwx_osx_cocoau_core-3.1.5.0.0.dylib`wxNonOwnedWindow::CanSetTransparent() + 11
    frame #1: 0x0000000104cca250 libwx_osx_cocoau_aui-3.1.5.0.0.dylib`wxAuiManager::UpdateHintWindowConfig() + 96
    frame #2: 0x0000000104cc9a2b libwx_osx_cocoau_aui-3.1.5.0.0.dylib`wxAuiManager::SetManagedWindow(wxWindow*) + 715
    frame #3: 0x0000000104b5adc1 _aui.cpython-39-darwin.so`meth_wxAuiManager_SetManagedWindow(sipSelf=0x0000000104ad2e50, sipArgs=0x0000000104ad08b0, sipKwds=0x0000000000000000) at sip_auiwxAuiManager.cpp:1454:21
    frame #4: 0x00000001001c50e0 Python`cfunction_call + 52
    frame #5: 0x000000010017a71e Python`_PyObject_MakeTpCall + 129

// ...

Now I am not able to see any variables and mapped source code related to this frame that the crash was happed.

fr v command gaves me empty result and source info gave me a error like below

(lldb) source info
error: No debug info for the selected frame.

Now I am not sure hot to find Debug info for this frame and map source code to this frame.

The dynamic library file this frame use is libwx_osx_cocoau_core-3.1.5.0.0.dylib.

BTW, my question now is that how could I set the source code and debug symbol into this frame?

I am able to set break point on file sip_auiwxAuiManager.cpp not ext/wxWidgets/src/aui/framemanager.cpp which is related to

libwx_osx_cocoau_aui-3.1.5.0.0.dylib`wxAuiManager::SetManagedWindow(wxWindow*)

back trace of frame where crash is

(lldb) bt
* thread #2, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001041b011b libwx_osx_cocoau_core-3.1.5.0.0.dylib`wxNonOwnedWindow::CanSetTransparent() + 11
    frame #1: 0x0000000104ce2250 libwx_osx_cocoau_aui-3.1.5.0.0.dylib`wxAuiManager::UpdateHintWindowConfig() + 96
    frame #2: 0x0000000104ce1a2b libwx_osx_cocoau_aui-3.1.5.0.0.dylib`wxAuiManager::SetManagedWindow(wxWindow*) + 715
    frame #3: 0x0000000104b72dc1 _aui.cpython-39-darwin.so`meth_wxAuiManager_SetManagedWindow(sipSelf=0x0000000104aeae50, sipArgs=0x0000000104ae88b0, sipKwds=0x0000000000000000) at sip_auiwxAuiManager.cpp:1454:21

Thank you anyone who read this question for your time

I see seg fault crashes in MacOS fairly commonly in code that runs fine on Windows. Usually it is due to a callback accessing a widget that has already been deleted, but in this case perhaps the problem is that something has not been created. It appears you have already determined where the crash is happening, but for anyone else reading this thread with a similar problem, sometimes there is no choice but to litter code with print()'s to find out what section of code is causing the crash. Usually putting that into a wx.CallAfter() does the trick; occasionally that does not work and a wx.CallLater(100,…) is needed.

Brian