Bug 337140

Created attachment 87594 [details]
crash log

Crash might be caused by QDBus.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libQt5DBus_debug.5.dylib      	0x00000001105b52dc QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::data() const + 12 (qscopedpointer.h:143)
1   libQt5DBus_debug.5.dylib      	0x00000001105b46a5 QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::pointer qGetPtrHelper<QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> > >(QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> > const&) + 21 (qglobal.h:941)
2   libQt5DBus_debug.5.dylib      	0x00000001105b4a6c QDBusAbstractInterface::d_func() + 28 (.qdbusabstractinterface.h:156)
3   libQt5DBus_debug.5.dylib      	0x00000001105b335e QDBusAbstractInterface::callWithArgumentList(QDBus::CallMode, QString const&, QList<QVariant> const&) + 62 (qdbusabstractinterface.cpp:446)
4   libQt5DBus_debug.5.dylib      	0x00000001105b4422 QDBusAbstractInterface::internalConstCall(QDBus::CallMode, QString const&, QList<QVariant> const&) const + 50 (qdbusabstractinterface.cpp:823)
5   libQt5DBus_debug.5.dylib      	0x000000011058c6b8 QDBusConnectionInterface::registeredServiceNames() const + 104 (qdbusconnectioninterface.cpp:200)
6   libkdeinit5_kate.dylib        	0x000000010cc17c8c fillinRunningKateAppInstances(QMap<QString, KateRunningInstanceInfo*>*) + 76 (katerunninginstanceinfo.cpp:33)
7   libkdeinit5_kate.dylib        	0x000000010cc1fed1 kdemain + 10033 (main.cpp:180)
8                                 	0x000000010cba5f72 main + 34 (kate_dummy.cpp:3)
9   libdyld.dylib                 	0x00007fff85e555fd start + 1

Hi Christoph, what do you suggest to investigate this further? Greets, Marko

Hi, IMHO that looks like dbus is not working properly. Does that happen for other apps, too?

Well, MacPorts' dbus is running:
---
$ port installed dbus
The following ports are currently installed:
  dbus @1.8.6_0 (active)
$ ps ax | grep dbus
11031   ??  S      0:00.01 /opt/local/bin/dbus-daemon --nofork --session
---

Qt's apps (Assistant.app etc.) start without problems, but when I try to start qdbusviewer.app it says "Error: Cannot connect to D-Bus:" without more details!

But at least it doesn't crash like kate.

Guess this is a starting point now.

Git commit 3ffbb1061f16a493502f899df47edfa3515a28fa by Christoph Cullmann.
Committed on 20/07/2014 at 11:09.
Pushed by cullmann into branch 'frameworks'.

fix crash if no dbus available

M  +175  -164  kate/src/main.cpp

http://commits.kde.org/kate/3ffbb1061f16a493502f899df47edfa3515a28fa

Please try out my commit ;)
Should avoid crashing at least, I hope.

This is what I now see on the console:
---
$ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kde/applications/kate/inst/Applications/KF5/kate.app/Contents/MacOS/kate 
Available methods:  ("Stat", "QFileSystemWatcher") preferred= QFSWatch
kate: createDoc 

Segmentation fault: 11
---

and the crash log has changed now.

Will add it right away.
---

While doing this test I realise that the logical dependency information for kate isn't correct, which made me build always master instead of frameworks. :-/
(Guess I need to update that for kate just as I did it for some other apps lately.)

Created attachment 87826 [details]
crash log after applying 3ffbb1061f16a493502f899df47edfa3515a28fa

This needs to be reopened, as it still crashes, although somewhere else.

P.S.: The logical dependency information is correct, as I've verified. (The problem was that I was updating to branch jenkins locally and therefore I wasn't seeing your commit at first.)

Sure, if it now crashes in createDoc that is still not fixed ;)
Will take a look.

Hmm, that really looks like a deeper problem, in kservice.
Looks like in kate's main.cpp there is the dbus stuff used without any check that it is available.

I wouldn't be surprised if this is a deeper lying problem with service or whatever!

The problem might in fact well be caused by the way my OSX/CI system is currently setup with respect to Qt standard paths, since those aren't yet correct!

Assuming it is caused by my setup, STILL, I believe the KF5 framework and apps should fail gracefully with sensible error messages, so that one knows what's going on without being forced into real crashes - which ask for a debugger.

BTW, I had tried the same with khelpcenter a while ago, with a slightly different result:
---
$ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kde/workspace/khelpcenter/inst/Applications/KF5/khelpcenter.app/Contents/MacOS/khelpcenter 
Could not find drkonqi at /opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/kcrash/inst/lib/libexec/drkonqi
"Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)"
$ ps ax | grep dbus
11031   ??  S      0:00.01 /opt/local/bin/dbus-daemon --nofork --session
96965 s017  S+     0:00.01 grep dbus
---
As you can see, although dbus IS running khelpcenter claims it is not.

On top of that it can't start DrKonqi.

BUT, it doesn't crash as kate does! :)

OK, I'll have to dive into the QStandardPaths patch eventually.

BTW, konversation also doesn't quit non-gracefully:

---
$ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/extragear/network/konversation/inst/Applications/KF5/konversation.app/Contents/MacOS/konversation 
unnamed app: set session bus address to "unix:path=/tmp/launch-F2kEmm/unix_domain_listener"
QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
KUniqueApplication: Cannot find the D-Bus session server:  "" 
---

(In reply to Christoph Cullmann from comment #12)
> Hmm, that really looks like a deeper problem, in kservice.

I do not know if this is relevant, but I just discovered and fixed a deep-seated bug in kdeinit4 (in my test version of KDE 4, but the same bug exists in the Frameworks code). See https://projects.kde.org/projects/frameworks/kinit/repository/revisions/master/entry/src/kdeinit/kinit.cpp#L122

There is no environment variable "MAC_DISPLAY" in Apple OS X. It should just be "DISPLAY".

The effect of the bug is that, on Apple OS X, the display ID does not get appended to the name of the socket on which kdeinit4 "listens" for requests to start programs. Consequently it does not "hear" anything, because "callers" (such as KCrash) do append the display ID to the socket name and are trying to connect on a different socket.

That said, I do not know if $DISPLAY exists in Marko's test setup. I am using OS X 10.7.5 (Lion) and I think Marko is using 10.9.x (Mavericks). When googling about $DISPLAY and Apple OS X, I saw some mutterings about $DISPLAY disappearing from the latest versions of Apple OS X.

I do see a DISPLAY variable here on 10.9.4:
---
$ set | grep DISPLAY
DISPLAY=/tmp/launch-k1vpuF/org.macosforge.xquartz:0
---

I'll try to patch away MAC_DISPLAY from said kinit code now...

But wait, as described in comment #5, even Qt5's dbusbiewer.app cannot find dbus!

So, I am afraid such a patch wouldn't help much...

STOP, now I see that the DISPLAY variable only exists on my *host*!

The Mavericks guest VM does NOT have a DISPLAY variable, seemingly because I did not install XQuartz on the OSX/CI system at all.

I guess, the question is, how KDE handles the case of an Aqua-based Qt4/5 installation.

OK, there is also GOOD news, ONE at least:

kalgebra is the 1st KF5 application which started for me just fine without crashing due to a missing dbus.

Well, could be it is not making use of dbus at all and therefore works out of the box...

(In reply to Marko Käning from comment #5)
> ... when I try to start qdbusviewer.app it says "Error: Cannot connect to D-Bus:" 

After rebuilding qt5 with configure option "-dbus-linked" instead of "-dbus" all Qt5 
applications can be started successfully and qdbusviewer.app lists
"org.freedesktop.DBus" and ":1.2" as existing and shows "Connected to D-Bus."

OK, I finally could run kate with kate being able to connect to dbus.

Since I am not yet having QStandardPaths fixed accordingly, problems accessing config files etc. still had to be expected...

Unfortunately these problems also lead to a crash of the application.

I'll attach the crash log as well as kate's output on the console.

Created attachment 88378 [details]
kate's console output

Created attachment 88379 [details]
kate's crashlog

Has this version of Kate been ported to Frameworks?

It certainly looks as though it is crashing in its handling of something that has changed from KDE 4 to KF5, not something that is dependent on OS X, unless perhaps the graphics system is wrong (i.e. not Raster).

If all else is OK, cancel this report and start another?

(In reply to Ian Wadham from comment #26)
> Has this version of Kate been ported to Frameworks?
Yes.

> It certainly looks as though it is crashing in its handling of something
> that has changed from KDE 4 to KF5, not something that is dependent on OS X,
> unless perhaps the graphics system is wrong (i.e. not Raster).
OK, I have used "QT_GRAPHICSSYSTEM=raster" to start kate and then I get indeed
other behaviour. Later errors persist as one can see from the logs which I'll 
attach. (Those errors might well be caused by that the applications doesn't have
the correct search paths to locate its files!)

Created attachment 88401 [details]
crash log for starting using raster graphics system

Created attachment 88402 [details]
console output for the case of starting with graphics raster system

(In reply to Marko Käning from comment #27)
> OK, I have used "QT_GRAPHICSSYSTEM=raster" to start kate and then I get indeed
> other behaviour. Later errors persist as one can see from the logs which I'll 
> attach. (Those errors might well be caused by that the applications doesn't have
> the correct search paths to locate its files!)

There are certainly several files missing, including the crucial *ui.rc file. Without that, no KDE app can get far. It defines the program actions and menu structure.

I do not know anything about Kate: never use it. But I would guess that missing KTextEditor/Plugin and "Error: standard icon theme "oxygen" not found!" are also rather crucial. Even the Kate session file might be crucial. Maybe, as a temporary measure, you could use KDE environment variables to force KDE to look in the "right" places (i.e. wherever Qt-Mac 5 puts them).

In the crash report, I notice that Kate is a KDEINIT type of app, which is a library loaded by kinit (kdeinit5?) and is entered via "kdemain". Also, the log shows that kded5 is not starting. My guess is that you are running into some of the same problems with kinit, kded and klauncher on Apple OS X and Frameworks as I have been getting with KDE 4 on Apple OS X.

I predicted this, but the Frameworks developers apparently have neither listened nor cared. I would put Kate and all KDEINIT type apps on the back burner for now, until some help is forthcoming.

The messages like "Shortcut for action  "view_split_vert" "Split Ve&rtical" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead." are also rather odd. Hasn't Frameworks moved away from KAction towards QAction? Why is the message saying to use KDE stuff? Is this a KF 5 porting problem in Kate?

Kate will start, even if no plugins or stuff like that is found. But not without any usable icon/ui file.

You'll find an update problems with KF5's Kate on OSX/CI in http://mail.kde.org/pipermail/kde-mac/2014-December/002626.html

I seem to have a quite functional kate after all.

Only problems left:

 1) It cannot find the hicolor icon theme

 2) It crashes at exit

Screenshot and crash logs can be found in above thread. (Shall I attach them here also?)

Can we close this bug then? The kservice side of it seems fixed?

(In reply to David Faure from comment #33)
> Can we close this bug then? The kservice side of it seems fixed?

As I am currently not dealing with KF5 on OSX I'll close this, since you think it is invalid or resolved by now.