Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Build on MacOS 10.8

edited November 2012 in General
Hi,
I have been building klayout-0.22.2 under MacOS 10.8 with qt-mac-opensource-4.8.3 using the suggested build options:

./build.sh -platform mac-leopard-gcc-release \
-qtbin /Developer/Tools/Qt \
-qtlib /usr/lib \
-rblib /usr/lib/libruby.dylib \
-rbinc /usr/lib/ruby/1.8/universal-darwin12.0

(without QT-bindings)
and it compiles like a charm. If I open the file with klayout.app from
the command line "open klayout.app" it opens klayout without any problems.

If I open it by double clicking the file from finder it immediately crashes, giving
the appended, shortened, bug report.

I don't know where to look for the reason. On stackoverflow somebody discussed
such behavior could appear with the working directory defaulting to / with the
execution finder but the cwd with the console.

Older versions of klayout did work fine my mac, I was using the precompiled builds
though. Maybe one exception, double clicking on a gds-file does open klayout but
not the file. I guess that has to do with the way mac os x passes the filename to the
running program.

Thank you for your help.

Cheers,

Hannes



Process: klayout [6349]
Path: /Users/USER/*/klayout.app/Contents/MacOS/klayout
Identifier: klayout.de
Version: 0.22.2
Code Type: X86-64 (Native)
Parent Process: launchd [288]

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff89462212 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff93f1aaf4 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff93f5edce abort + 143
3 QtCore 0x000000010ef16685 qt_message_output(QtMsgType, char const*) + 117
4 QtCore 0x000000010ef16867 qt_message(QtMsgType, char const*, __va_list_tag*) + 183
5 QtCore 0x000000010ef16a2a qFatal(char const*, ...) + 170
6 QtGui 0x000000010e2eb355 QWidgetPrivate::QWidgetPrivate(int) + 853
7 QtGui 0x000000010e2ffa0b QWidget::QWidget(QWidget*, QFlags) + 59
8 QtGui 0x000000010e257c59 QDesktopWidget::QDesktopWidget() + 41
9 QtGui 0x000000010e2a1e8b QApplication::desktop() + 59
10 QtGui 0x000000010e252fab flipPoint(CGPoint const&) + 27
11 QtGui 0x000000010e24e645 -[QCocoaWindowDelegate windowDidMove:] + 133
12 com.apple.CoreFoundation 0x00007fff89fa947a _CFXNotificationPost + 2554
13 com.apple.Foundation 0x00007fff8d41d846 -[NSNotificationCenter postNotificationName:object:userInfo:] + 64
14 com.apple.AppKit 0x00007fff8dcba421 -[NSWindow _setFrameCommon:display:stashSize:] + 1973
15 com.apple.AppKit 0x00007fff8dc114de -[NSWindow setFrameOrigin:] + 406
16 QtGui 0x000000010780b9d0 QWidgetPrivate::setGeometry_sys(int, int, int, int, bool) + 752
17 QtGui 0x00000001078c0da3 QWidget::resize(QSize const&) + 83
18 klayout.de 0x0000000105cc39da lay::Application::run() + 240
19 klayout.de 0x00000001054c9e8a klayout_main(int, char**) + 74
20 klayout.de 0x00000001054c9d78 main + 216
21 libdyld.dylib 0x00007fff900047e1 start + 1

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff89462d16 kevent + 10
1 libdispatch.dylib 0x00007fff8d372dea _dispatch_mgr_invoke + 883
2 libdispatch.dylib 0x00007fff8d3729ee _dispatch_mgr_thread + 54

Thread 2:
0 libsystem_kernel.dylib 0x00007fff894626d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff93f1beec _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff93f1bcb3 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff93f06171 start_wqthread + 13

Thread 3:
0 libsystem_kernel.dylib 0x00007fff894626d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff93f1beec _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff93f1bcb3 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff93f06171 start_wqthread + 13

Thread 4:
0 libsystem_kernel.dylib 0x00007fff894626d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff93f1beec _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff93f1bcb3 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff93f06171 start_wqthread + 13

Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x00007fff5a735e98 rdx: 0x0000000000000000
rdi: 0x0000000000000c07 rsi: 0x0000000000000006 rbp: 0x00007fff5a735ec0 rsp: 0x00007fff5a735e98
r8: 0x00007fff7ac0d278 r9: 0x00007fff5a735eb0 r10: 0x0000000020000000 r11: 0x0000000000000206
r12: 0x0000000000000003 r13: 0x00007fff5a735fa0 r14: 0x00007fff7ac0e180 r15: 0x0000000000040803
rip: 0x00007fff89462212 rfl: 0x0000000000000206 cr2: 0x00007fff7ac06fe8
Logical CPU: 0

Comments

  • edited 9:49PM

    Hi Hannes,

    I still don't own MacOS hardware, so I can just guess. The stack trace does not show any obvious reason for the crash. In fact the crash appears to happen almost at the very beginning of the code before the real stuff happens.

    So I somewhat suspect a very basic problem. Are there known issues with Qt and MacOS (I've heard rumours but as I said I don't have any experience myself).

    The line where the crash happens is found in layApplication.cc, line 782:

    mp_mw->resize (800, 600);
    

    But that statement is perfectly valid Qt code.
    Maybe you can comment out that line (it's not really required) and check whether it gets further.

    Regards,

    Matthias

  • edited 9:49PM
    Hi Matthias,

    a quick check gave unfortunately not a different
    behavior.
    I'll try a older version of qt as a check.

    Thanks,

    Hannes
  • edited 9:49PM
    Hi Hannes, Matthias,

    Exact same problem here. Build went fine with instructions on the Download & Build page. When I start klayout from the command line it loads, when double-clicked it crashed immediately.

    Klayout only open properly when started from the Terminal. It doesn't work if I use a script or applescript. Maybe this is something to do with environment variables set in the terminal?
  • edited 9:49PM
    Here's a quick clunky Mac solution to get Klayout working as a clickable app. Save the code below as an Applescript application (or download from https://dl.dropbox.com/u/15963994/Klayout%20opener.zip ):


    tell application "System Events"
    set termRunning to (exists process "Terminal")
    end tell

    tell application "Terminal"
    do script "open /Applications/klayout.app; exit"
    if termRunning is false then
    delay 4
    quit
    end if
    end tell
  • edited 9:49PM
    Hi Dtsimon, Matthias,

    thanks for the script, it works fine also on my machine.

    Regarding the initial problem. Before I got distracted to something else, I hunt it
    down to the library loading mechanism on mac os x. When the .app bundle is created the the Qt-Library is copied into it and the klayout binary gets the information to look at first in the bundle path for them :
    ( otool -L klayout )
    klayout:
    /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib (compatibility version 1.8.0, current version 1.8.7)
    @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.6.0, current version 4.6.4)
    @executable_path/../Frameworks/QtXml.framework/Versions/4/QtXml (compatibility version 4.6.0, current version 4.6.4)
    @executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.6.0, current version 4.6.4)
    @executable_path/../Frameworks/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.6.0, current version 4.6.4)
    @executable_path/../Frameworks/QtSql.framework/Versions/4/QtSql (compatibility version 4.6.0, current version 4.6.4)
    @executable_path/../Frameworks/QtDesigner.framework/Versions/4/QtDesigner (compatibility version 4.6.0, current version 4.6.4)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

    Somehow, if executed from the finder something fails there.
    When I remove the contents of "@executable_path/../Frameworks/" in the .app bundle or modify the path with the "Install_name_tool" to point to the system wide Qt-libs it has been compiled against, it executes from finder.

    It does also not matter which qt 4.X version I use to compile klayout.

    It may be something odd with my system as well, but on a Mac OS X 10.6.8 without a QT-lib installation I looked at briefly, my compile immediately crashes. Always.

    Cheers, Hannes
  • edited 9:49PM

    Hi all,

    I wish I could help with that, but so far I am not equipped with MacOS hardware that would enable me doing so ...

    Matthias

  • edited 9:49PM
    Hi Matthias,

    I'm a step further...
    The relevant environment variables on the command line are the LANG and or LC_ALL parameters. When these are not properly set, klayout also crashes when called from the command line.
    With this gdb can be used.
    Okay, there is a problem with QT libraries present twice, lots of warings like this:

    ---
    objc[36464]: Class QNSImageView is implemented in both klayout-0.22.4/bin.mac-leopard-gcc-release/klayout.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui and /Library/Frameworks/QtGui.framework/Versions/4/QtGui. One of the two will be used. Which one is undefined.
    Warning: QObject::moveToThread: Current thread (0x10a4150c0) is not the object's thread (0x112646e30).
    ---

    and

    ---
    Warning: On Mac OS X, you might be loading two sets of Qt binaries into the same process. Check that all plugins are compiled against the right Qt binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of binaries are being loaded.
    Warning: QObject::moveToThread: Current thread (0x10a4150c0) is not the object's thread (0x112646e30).
    Cannot move to target thread (0x10a4150c0)

    Warning: On Mac OS X, you might be loading two sets of Qt binaries into the same process. Check that all plugins are compiled against the right Qt binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of binaries are being loaded.
    ---

    and this at the end:
    ---
    QWidget: Must construct a QApplication before a QPaintDevice
    ---
    which is in my opinion the key to the problem.
    Somebody already had this entirely MAC OS X bundle problem before:

    http://code.mythtv.org/trac/ticket/9447

    It seems that calling QPaintDevice requires a existing QApplication and there is
    some problem with the internationalization attached. The specialty on MAC OS X is,
    in my simplified understanding, that two identical libraries can be loaded from the two places, the system and the bundle. When the language is not properly initialized, the qt.conf in the bundle is not read and the loader is confused which library to load and crashes eventually.

    However, I did not figure where the QPaintDevice gets constructed before the QApplication yet.

    Maybe you have a clue where this could be in the klayout sources, Matthias ?

    Thanks,

    Hannes
  • edited 9:49PM

    Hi Hannes,

    that does not look quite good ...

    Frankly, I don't understand why the MacOS build became such a problem. Until roughly a year ago, the build apparently was pretty straightforward ...

    Regarding the QPaintDevice: I don't instantiate one but the windows represent a QPaintDevice. So basically the message says, a Widget is created before the QApplication object. This message should also appear on Linux (which is doesn't), so I suspect some other issue.

    The QApplication object is created at the very beginning ("main" calls "klayout_main" which instantiates "lay::Application" which creates the QApplication in the constructor. So there is not much that can happen before that. You could try to add some output statements to figure out when the mysterious Widget gets created before QApplication is.

    Because you mentioned "LANG": in earlier versions I was setting "LANG" inside the code to "C" to prevent a crash on some Linux installations because of issues with the X11 library and UTF-8 encoding. I removed that code about 2 years ago because it turned out to be not required any longer. Maybe that masked the LANG issue on MacOS. You can try to enable that code again by adding something like

    #if defined(Q_WS_MAC)
      putenv ((char *) "LANG=C");
    #endif
    

    right at the beginning of main().

    Best regards,

    Matthias

  • edited 9:49PM
    Hi Matthias,

    I stepped through main() with your putenv advice and the problem seems to
    be the function tl::system_to_string() from the tlInternational.cc file.
    There a QTextCodec object and a QString is instantiated, one of those causes the crash. They are both instantiated before QApplication, which is consistent with the previous observation.
    Interestingly, setting LANG=C or LANG=POSIX does not work, as it is also not from the shell. One has to set a locale like "en_US".

    I guess that the locale function "nl_langinfo (CODESET)" fails on MAC OS when no environment variable is defined (as it is when opened by the finder).
    My workaround was to set the codec fixed to "Latin-1" in tlInternational.cc like
    this:

    void initialize_codecs ()
    {
    // determine encoder for system strings
    #ifdef _WIN32
    ms_system_codec = 0;
    #elif defined(Q_WS_MAC)
    ms_system_codec = QTextCodec::codecForName ("Latin-1");
    #else
    setlocale (LC_ALL, "");
    ms_system_codec = QTextCodec::codecForName (nl_langinfo (CODESET));
    if (! ms_system_codec) {
    ms_system_codec = QTextCodec::codecForName ("Latin-1");
    }
    #endif

    This seems to work now also from finder.

    Best regards,

    Hannes
  • edited 9:49PM

    Hi Hannes,

    thank you for that hint about nl_langinfo. I'll include that in the code.

    However, I have one remark. Actually it's something that needs testing. The system locale is used basically in two places: when decoding environment variables and when decoding the arguments given on the command line when the klayout executable is called.

    In both cases, the system locale is used to convert these strings into Unicode (more precisely UTF8) representation. On Windows, that is not an issue - Windows offers wide-character versions of both getenv() and main() with full Unicode support so there is translation required. On Linux, there are only 8bit-Versions of these functions, so it is important to look for the proper encoding of the application environment and to translate these strings into Unicode accordingly. On Linux the encoding is usually UTF-8 today, so that it is possible for example to use filenames with chinese characters on Linux too.

    For MacOS, I can't tell. I assume it's also something like UTF-8 so that a proper choice would be "en_US.UTF-8" instead of "Latin-1".

    I have found something about some function called "CFStringGetSystemEncoding" here. Maybe that is the proper way to determine the system encoding.

    When the implementation is correct, you should be able to open a file with Chinese characters on the command line using "klayout file_with_chinese_name.gds".

    That is all guessing. As I mentioned in the other post, I don't have MacOS to play with right now.

    Best regards,

    Matthias

  • edited 9:49PM
    Hi Matthias,

    you are right, the MAC OS line should be UTF-8:

    ms_system_codec = QTextCodec::codecForName ("UTF-8");

    and not Latin-1, which was working because I tested it with only ascii
    characters. With the above change, it works also fine with German Umlauts
    in the filename.
    It is save to assume UTF-8 encoding for all filenames and variables on fairly recent MAC OS X (not on old MAC OS).
    However, as described on the website you mentioned, one could bother and take also the usually unset LANG variables into account and set the encoding the way you do it for Linux. In my opinion, this should only rarely be necessary, though.

    The reason why I had the LANG variables in my MAC OS X shell was simply laziness. I'm using a copied .zshrc from a Linux box, where it was setup.

    Thanks & best regards,

    Hannes
Sign In or Register to comment.