wx crashes (pointer being freed was not allocated)

Issue #65 resolved
Bouke Haarsma
created an issue

Simple test case (source):

import wx
app = wx.App(False)
frame = wx.Frame(None, wx.ID_ANY, "Hello World")
frame.Show(True)
app.MainLoop()

Having installed wxwidgets 2.9 with brew (brew install wxmac), building an app with py2app will throw the following error when trying to run:

objc[2428]: Class wxNSAppController is implemented in both ./dist/[app].app/Contents/Frameworks/libwx_osx_cocoau_core-2.9.4.0.0.dylib and ./dist/[app].app/Contents/Frameworks/libwx_osx_cocoau_core-2.9.dylib. One of the two will be used. Which one is undefined.
(...)
[app](2428,0x7fff78376180) malloc: *** error for object 0x1049f3240: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap: 6

This issue is not present in 0.6.4 and does not affect alias mode, using the current repo version.

Comments (11)

  1. Ronald Oussoren repo owner

    brew is building wxmac on my machine.

    The problem is likely that one of the two libraries is a symlink in the homebrew tree and py2app doesn't notice that. The result of that is that the application loads two copies of wxWidgets and that can't work.

    If I'm correct there is a quick workaround until I have a proper fix: remove one of the dylibs from the application bundle and replace it by a symlink to the other dylib.

  2. Bouke Haarsma reporter

    The quick workaround worked for me, thanks! I have added these lines to my build script:

    cd "dist/[app].app/Contents/Frameworks/"
    IFS='
    '
    for FILE in `ls *4.0.0.dylib*`; do
        echo "Symlinking ${FILE/4.0.0./}"
        rm "$FILE"
        ln -s "${FILE/4.0.0./}" "$FILE"
    done
    

    For your information, these are the duplicate packages:

    libwx_baseu-2.9.4.0.0.dylib
    libwx_baseu-2.9.dylib
    libwx_baseu_xml-2.9.4.0.0.dylib
    libwx_baseu_xml-2.9.dylib
    libwx_osx_cocoau_adv-2.9.4.0.0.dylib
    libwx_osx_cocoau_adv-2.9.dylib
    libwx_osx_cocoau_core-2.9.4.0.0.dylib
    libwx_osx_cocoau_core-2.9.dylib
    libwx_osx_cocoau_html-2.9.4.0.0.dylib
    libwx_osx_cocoau_html-2.9.dylib
    
  3. Mika Seppänen

    That fix breaks it for us. Our application loads libGeoIP.dylib, which is symbolic link to libGeoIP.1.dylib. Now file named libGeoIP.1.dylib ends up to our application bundle and our application fails to start because it can't find library named libGeoIP.dylib.

    As a workaround I can of course revert that change locally, but it would be nice to find a solution that works for both cases. Maybe something has changed in the way py2app finds libraries?

  4. Ronald Oussoren repo owner

    Both the 0.7 branch and the default branch now contain a testcase that verifies that both the dylib and the symlink are copied (and the testcase passes due to a change in the same commit), that should fix the issue.

  5. Log in to comment