[KDE/Mac] More debugging on OSX, now using lldb (since running on Mavericks)

[Marko Käning]

Hi folks,

I was able to start and stop the application konversation on MacPorts using Xcode as
well as lldb on the console, which might have implications for René’s RR 120510 [1].

(But, still, I don't know how to be able to diagnose where konversation is actually
 hanging out at some specific point in time.)

In Xcode I was able to see the application running, with cpu, memory, energy imp ace,
disk and network being logged.

When interrupted I could only see where the application was entered, i.e. at
---
return app.exec();
---
in thread 1.

Furthermore I saw that:

- threads 2 and 3 where OSX-specific.

  + thread 2: libdispatch.dylib`_dispatch_mgr_thread

  + thread 3: libsystem_pthread.dylib`thread_start  (same for all other running threads)

- thread 4: is named QKqueueFileSystemWatcherEngine

- all other running threads had no specific name.


If I now interrupt the running session I can browse the currently opened threads, but
I see only the threads’ assembler code like this:
---
libsystem_pthread.dylib`start_wqthread:
0x7fff81c46fac:  pushq  %rbp
0x7fff81c46fad:  movq   %rsp, %rbp
0x7fff81c46fb0:  subq   $0x18, %rsp
0x7fff81c46fb4:  callq  0x7fff81c43dbe            ; _pthread_wqthread
0x7fff81c46fb9:  leave  
0x7fff81c46fba:  retq   
0x7fff81c46fbb:  nop    
---
and no konversation source code at all. (Thread 1 is the only exception.)

I want to understand, where konversation idles around after having been minimised (see
this bug [2]), but although I can reproduce the hanging GUI in Xcode I am unable to
see where exactly the application is on a "walkabout" - to use Aussie terminology… =)

Any pointers for an Xcode- and OSX-inexperienced guy like me?

Greets,
Marko


P.S.: I now realise that I haven’t tried to use Qt-Creator yet... Perhaps that’s a
      another alternative! =)



[1] https://git.reviewboard.kde.org/r/120510/
[2] https://bugs.kde.org/show_bug.cgi?id=339713