DevHeads.net

Review Request 119497: Report crashes of KDE apps in Apple OS X (1)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.

Repository: kdelibs

Description
When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"

It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.

So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two...

In this review we have two portability problems:

1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely.

2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash.

This "deafness" of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment.

Diffs
kdeui/util/kcrash.cpp 45eb46b
kinit/kinit.cpp e41845a

Diff: <a href="https://git.reviewboard.kde.org/r/119497/diff/" title="https://git.reviewboard.kde.org/r/119497/diff/">https://git.reviewboard.kde.org/r/119497/diff/</a>

Testing
Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.

Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.

I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software.

Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports:
KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0
Warning: connect() failed: : No such file or directory

With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating).

I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.

Thanks,

Ian Wadham

Comments

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 07/27/2014 - 04:15

(Updated July 27, 2014, 9:15 a.m.)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.

Summary (updated)
Report crashes of KDE apps in Apple OS X (1) (fix kcrash, kinit)

Repository: kdelibs

Description
When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"

It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.

So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two...

In this review we have two portability problems:

1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely.

2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash.

This "deafness" of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment.

Diffs
kdeui/util/kcrash.cpp 45eb46b
kinit/kinit.cpp e41845a

Diff: <a href="https://git.reviewboard.kde.org/r/119497/diff/" title="https://git.reviewboard.kde.org/r/119497/diff/">https://git.reviewboard.kde.org/r/119497/diff/</a>

Testing
Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.

Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.

I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software.

Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports:
KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0
Warning: connect() failed: : No such file or directory

With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating).

I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.

Thanks,

Ian Wadham

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/14/2014 - 20:39

(Updated Sept. 15, 2014, 1:39 a.m.)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.

Changes
This is a new patch for KCrash only (on KDE 4), to prevent it crashing on Apple OS X and to make it start Dr Konqi on Apple OS X only by forking, because starting Dr K via kdeinit4 always fails on Apple OS X. The patch also incorporates ideas arising in previous reviews and closes the relevant issues.

The proposed changes to kinit/kinit.cpp (kdeinit4) have been discontinued temporarily. This is because I appealed for help and answers to some questions about kdeinit4, klauncher, kwrapper and kded4 and how they should interact with each other and with applications, but I was not able to get that help and those answers. So KDE 4 software on MacPorts and Apple OS X will continue as before, making minimal to zero use of those background processes.

Repository: kdelibs

Description
When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"

It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.

So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two...

In this review we have two portability problems:

1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely.

2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash.

This "deafness" of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment.

Diffs (updated)
kdeui/util/kcrash.cpp 45eb46b

Diff: <a href="https://git.reviewboard.kde.org/r/119497/diff/" title="https://git.reviewboard.kde.org/r/119497/diff/">https://git.reviewboard.kde.org/r/119497/diff/</a>

Testing
Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.

Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.

I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software.

Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports:
KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0
Warning: connect() failed: : No such file or directory

With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating).

I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.

Thanks,

Ian Wadham

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/14/2014 - 20:59

(Updated Sept. 15, 2014, 1:59 a.m.)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.

Summary (updated)
Report crashes of KDE apps in Apple OS X (1) (fix kcrash)

Repository: kdelibs

Description (updated)
*NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp (kdeinit4) have been discontinued. For a summary, scroll to the very end of this page.

When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"

It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.

So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two...

In this review we have two portability problems:

1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely.

2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash.

This "deafness" of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment.

Diffs
kdeui/util/kcrash.cpp 45eb46b

Diff: <a href="https://git.reviewboard.kde.org/r/119497/diff/" title="https://git.reviewboard.kde.org/r/119497/diff/">https://git.reviewboard.kde.org/r/119497/diff/</a>

Testing
Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.

Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.

I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software.

Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports:
KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0
Warning: connect() failed: : No such file or directory

With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating).

I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.

Thanks,

Ian Wadham

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/16/2014 - 06:14

(Updated Sept. 16, 2014, 11:14 a.m.)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.

Changes
Patches for reviews 119497 and 119498 are an inter-dependent pair, but on two different KDE 4 repositories.

Repository: kdelibs

Description
*NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp (kdeinit4) have been discontinued. For a summary, scroll to the very end of this page.

When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"

It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.

So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two...

In this review we have two portability problems:

1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely.

2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash.

This "deafness" of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment.

Diffs
kdeui/util/kcrash.cpp 45eb46b

Diff: <a href="https://git.reviewboard.kde.org/r/119497/diff/" title="https://git.reviewboard.kde.org/r/119497/diff/">https://git.reviewboard.kde.org/r/119497/diff/</a>

Testing
Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.

Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.

I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software.

Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports:
KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0
Warning: connect() failed: : No such file or directory

With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating).

I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.

Thanks,

Ian Wadham

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/23/2014 - 20:01

(Updated Sept. 24, 2014, 1:01 a.m.)

Status
This change has been marked as submitted.

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.

Repository: kdelibs

Description
*NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp (kdeinit4) have been discontinued. For a summary, scroll to the very end of this page.

When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"

It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.

So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are submitted in this review. Patches for three more are submitted in part 2 of this review, against kde-runtime. I am still investigating the other two problems in Dr Konqi - and there could be more than two...

In this review we have two portability problems:

1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X library (COCOA) and it crashes if they are closed prematurely.

2. The preferred way to start Dr K is via a socket message to kdeinit4, but that fails in Apple OS X because kdeinit4 is listening with the wrong socket name. The DISPLAY ID is missing from the end of the name. The fallback is for KCrash to use fork() and exec(), which works, but could cause Dr K to be polluted, depending on the nature of the crash.

This "deafness" of kdeinit4 (and klauncher) could be causing other failures in KDE software in the Apple OS X environment.

Diffs
kdeui/util/kcrash.cpp 45eb46b

Diff: <a href="https://git.reviewboard.kde.org/r/119497/diff/" title="https://git.reviewboard.kde.org/r/119497/diff/">https://git.reviewboard.kde.org/r/119497/diff/</a>

Testing
Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.

Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.

I NEED HELP from KDE -core- developers to proceed further. These problems also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks on Apple OS X. And I am sure there are many more Apple OS X portability problems in KDE software.

Without my patches, Dr Konqi is not started and, if it does get past its own crash, KCrash reports:
KCrash: Attempting to start /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0
Warning: connect() failed: : No such file or directory

With my patches, Dr Konqi can always be started directly (using fork()) and it -will- start via kdeinit4 and klauncher but it immediately runs into a privilege problem with Apple OS X (a problem which I am still investigating).

I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.

Thanks,

Ian Wadham

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?iso-8859-1?Q?... at 09/15/2014 - 14:26

Hi Ian, shall I test this on a Mavericks VM before you're committing this? In case I shall do it, do you have a test case for me? Greets, Marko

- Marko Käning

On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?iso-8859-1?Q?... at 09/16/2014 - 00:10

Sorry, above I don't mean issue, but review request 119498. :)

- Marko

On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?iso-8859-1?Q?... at 09/16/2014 - 00:06

If this depends on issue 119498 it would be good to enter that id in the "Depends On" field of this RR, I guess. That makes clearer what has to be installed to apply this patch cleanly, no?

- Marko

On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/15/2014 - 21:35

Thanks, but please wait until I drop the other shoe, review 119498, fix Dr Konqi.

The test case I use is to start Palapeli (jigsaw puzzle), open any puzzle and start dragging a piece, then, without letting go of the mouse button, hit menu item Game->Restart Puzzle. That will cause a crash every time. You need to set up and use a shortcut key for the Game->Restart Puzzle action (use Settings->Configure Shortcuts...).

- Ian

On Sept. 15, 2014, 1:59 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By David Faure at 09/15/2014 - 02:13

Ship it!

The "wrong socket name" sounds like a workaround for something that should be fixed anyway, but I have no objections to this going in; one step at a time.

- David Faure

On Sept. 15, 2014, 1:59 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Aleix Pol at 07/29/2014 - 10:33

kdeui/util/kcrash.cpp
<https://git.reviewboard.kde.org/r/119497/#comment44225>

Change to #elif?

The #if sequence is getting very deep to keep understandable.

kinit/kinit.cpp
<https://git.reviewboard.kde.org/r/119497/#comment44224>

do you need $DISPLAY in OS X?

- Aleix Pol Gonzalez

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Thoma... at 09/20/2014 - 17:32

Don't consider me one, sorry :-(
I'm looking at this code the first times myself now.
But lxr.kde.org would find every occasion of "kdeinit4_", so unless there's some supersmart "kdeinit4" + "_" + display, those are the relevant locations. I'f there is, we'll sooner or later hit it.

Did you open a bug on this (or record the codepoints somehwere)?

... because the cmake builds it w/o setting the NO_DISPLAY variable, i'd say (unlike kdeinit4_wrapper)

You're hopefully not talking about me, since I cannot recall having received such mails (or offered not existing expertise for advisory =)

Sure. kde-core-devel seems most suited to me (and *far* better than private mails) - I can just assume that Martin is very interested in making things work w/o DISPLAY being set (and ultimately we'll all be ;-)

- Thomas

On Sept. 16, 2014, 11:14 vorm., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Thoma... at 09/21/2014 - 06:17

The particular mistake in this context is the "implicit protocol".

The socket name isn't specified anywhere (luckily - it would likely mention "DISPLAY" ;-) and is not provided by a common function (KGlobal::sessionSocket() or so) either. Instead it's generated in different code sections.

No comment could be of any help here, because it would certainly not include "all other places where this is used:"

- Thomas

On Sept. 16, 2014, 11:14 vorm., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/20/2014 - 08:05

Now you are talking! Actually I hit on that kdeinit4_ search-string myself a while back, but could not be certain about exactly where all the edits of socket names should be, in order to make kdeinit4 and friends work on OS X and avoid breaking anything on any other platform. That is one place where I really needed expert help from a KDE core developer who knows kdeinit4 and friends.

David Faure has said, re an earlier issue in this RR, that it would be OK to make $DISPLAY an empty string on Apple OS X (the socket name would then end with kdeinit4_) and that would be fine by me ($DISPLAY no longer exists in OS X itself, only in the FOSS X11 called XQuartz).

In the course of seeking expert help, I discovered several other serious problems in kdeinit4, such as permanent blocking at several points in its initialisation, including one that might also exist in the Linux version. Another problem was that I once got all three of kdeinit4, klauncher and kded4 to run at once, but then kdeinit4_shutdown failed because it had the wrong socket name! I know why this is, BTW. I raised questions about these problems by emails to the person who had offered to help and advise me, but he never replied.

Thomas, could we discuss these problems somewhere else than here: kde-mac, kde-devel or kde-core-devel? I am a member of all three. Do you have the time? Would Martin Graesslin be interested too? IRC is difficult for me because my timezone is UTC + 10 (Australia).

- Ian

On Sept. 16, 2014, 11:14 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 09/21/2014 - 05:06

David already gave this a ShipIt 6.33 days ago ;)

Anyway, I've come to realise something that I'm sure you (Ian) realised too, but since I've not seen any mention of it I thought I'd voice it here. One of the reasons you've been so much in need of the guidance of a core KDE dev (like I'd be if I wanted to do more than the simple hacking I've been doing until now) is the cruel lack of comments in the code. Not to say there are none, and of course the use of classes and functions with long(ish) and explicative names partly removes the need for commenting - but that helps mostly when you already know the context and/or approach taken because it basically tells you not much more than what an "atomic" operation does, not why. I'm not a software developer by formal training, but one of my mentors once gave me a (somewhat caricatural ;)) rule of thumb: write 3 lines of comments for every 2 lines of code.

Just sayin' O:^)

- René J.V.

On Sept. 16, 2014, 1:14 p.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/20/2014 - 18:15

Thanks, Thomas, I am sure we'll manage somehow... :-)

I can line up all the socket names containing kdeinit4_ so that they have only $DISPLAY (on Linux) or empty string (on Apple OS X) appended, but I can only test that on Apple OS X, so I would be relying on you or Martin to check for regressions on Linux.

I did not open bug reports on the permanent blocking, but I did document them in emails to the guy who was going to help me (it was NOT you). I still have them on file. Kdeinit4_shutdown fails on Apple OS X because it runs as NOGUI, but kdeinit4 builds and runs as GUI on Apple OS X. They will realign their socket names if both of them append "" rather than "$DISPLAY" to the socket name on Apple OS X.

I will reopen this discussion on kde-core-devel, probably around Tuesday. I have busy days today and Monday.

Meanwhile, I wonder if you could give 119498 a "Ship It"? Or can I do that myself?

- Ian

On Sept. 16, 2014, 11:14 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Thoma... at 09/20/2014 - 05:40

<a href="http://lxr.kde.org/search?_filestring=&amp;_string=kdeinit4_" title="http://lxr.kde.org/search?_filestring=&amp;_string=kdeinit4_">http://lxr.kde.org/search?_filestring=&amp;_string=kdeinit4_</a>

Only the three sources should be relevant (but I don't speak docbook)
This *will* be relevant for wayland at some point, so ideally get mgraesslin on the topic as well.

There's also a NO_DISPLAY definition in kinit and kcrash (since around 2006) which actually seems what you want to ensure being defined on OSX.
Applying the same approach (from kcrash.cpp & wrapper.c) to kinit.cpp (where it seems forgotten?) should fix socket generation.

- Thomas

On Sept. 16, 2014, 11:14 vorm., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/16/2014 - 06:31

The socket name is generated in 3 or 4 places, I am not sure how many. All of these must "line up" if KCrash, kdeinit4, klauncher, kded4 and kwrapper are to run as and when required and interact correctly on Apple OS X. And I am not even sure how much or how many of those background processes are really needed on Apple OS X or what their usual uses are or what their uses should be on Apple OS X or even whether new versions of all the processes are going to be used in KF5.

Until I can get some expert help and advice from a core KDE developer I am not going to touch any of that code. That is final.

- Ian

On Sept. 16, 2014, 11:14 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 09/16/2014 - 07:07

I think that's irrelevant. It's a blackbox ... so be it. We just know all apps must use the same $DISPLAY value. I'm pretty sure all apps also go through a shared KDE initialisation phase, probably part of kdelibs. Forcing the DISPLAY env. variable to a sensible, constant value at the start of that phase should set the variable as required. It's a hack, but we're probably not going to be able to do any nicer for KDE4.
KF5 will probable (hopefully)? evolve to using something other than $DISPLAY ... unless that same thing is used by Wayland!

R.

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 09/16/2014 - 02:57

I'm not sure why you're dropping this. Wouldn't the simplest solution be to make sure, somewhere at a very early stage (and I've seen places where it seems DISPLAY is being set/changed in the environment, from kdelibs!) that the variable is set to something sensible? Something that is a syntactically correct DISPLAY variable?

If we presume that KDE-mac never actually connects to an X11 server, it would make perfect sense to set DISPLAY=localhost:0 . Any code using the host information will get the correct host address out of this, the rest doesn't matter. Except that all clients will agree on the host they're displaying on.

- René J.V.

On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/14/2014 - 20:40

This part of the patch has been discontinued.

- Ian

On Sept. 15, 2014, 1:39 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Benjamin Reed at 07/31/2014 - 09:26

Ultimately, the point of using $DISPLAY in KDE is to be able to associate things happening in KDE with a unique user "session", and on Mac OS X, $DISPLAY is not in any way tied to the user's actual session. It can get reset or changed for any number of reasons, even though the user is in a single login session to the Mac desktop.

- Benjamin

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/31/2014 - 07:16

I've looked into the $DISPLAY value variations mentioned (= described from memory) above. The big lines hold:

- When I log in, $DISPLAY is not set. This is probably because I deactivated org.macosforge.xquartz.startx.plist (by moving it from Library/LaunchAgents): I always launch an X11 environment anyways and the autostart feature tends to start another server when I'm least expecting it.
- When I start XQuartz and launch (for instance) konsole, $DISPLAY remains unset, unless I launch konsole using `open -a konsole` typed into an xterm (i.e. with $DISPLAY set).
- The value $DISPLAY takes (initially) is ":0"
- ~/.MacOSX/environment.plist contains <key>DISPLAY</key><string>:0.0</string> but the file does not exist on all accounts I tried (which show the same behaviour, suggesting that the file is irrelevant).
- Quitting and restarting XQuartz normally does not modify the $DISPLAY value
- A crash (or SIGTERM, kill -9) of XQuartz DOES cause $DISPLAY to become ":1" after restarting the server
- This is a system-wide phenomenon that's not linked to a particular login session. In other words, if I log off and back in as a different user, starting XQuartz as that user will still set $DISPLAY=:1 . (If I'd had to guess, I'd say the crash/kill caused something like a shared memory segment to not be released.)
- One of the accounts I checked is a guest account in which Xquartz is started in a purely stock way (and had never been started before), without any attempts to set $DISPLAY to something not including a filepath.

In short, $DISPLAY doesn't necessarily have a file path (starting with "/tmp") value, and can indeed change during login session.

Testing was done on 10.6.8 and 10.9.2, using XQuartz.app maintained by Apple's Jeremy Huddleston. This is not the same as the (deprecated) X11.app that used to be distributed by Apple as an optional component of Mac OS X. It's the same server of which (at least) the local libraries are installed by MacPorts.

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/30/2014 - 07:21

I meant restarts of the X server - it does crash sometimes, sometimes I have to restart it for other reasons, like after logging off and back in. I recall that I used to have those weird (socket based?) $DISPLAY values too, but now they're of a perfectly normal host:X.Y form on my systems. Except that X tends to increase each time I start XQuartz. I ignore how common this is, but I think that if you're looking into the use of $DISPLAY on OS X, you could just as well take all possible situations into account. I'd suggest to use the fact that the actual value is irrelevant and without important to clamp it to something appropriate (why not Qt4:Mac) in such a way that all those younger components pick up that value. And not the actual, current value of $DISPLAY, which may or may not have remained unchanged. (I specifically used the term clamp to draw an analogy signal acquisition, where unconnected inputs can carry all kinds of bogus signals.)

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 07/30/2014 - 05:26

Restart of what? My system (Lion) has Apple OS X's XQuartz and $DISPLAY has a random temp-file path prepended every time Apple OS X starts of restarts. And that path is different every time. But so what? $DISPLAY keeps the same value no matter how many times I start XQuartz (X11) by running Gimp or whatever. And that value, determined immediately after boot or restart, should be picked by all KDE components, which come into existence later.

- Ian

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/30/2014 - 02:57

Hmm, interesting. I should find some time to play with this in my 10.9 VM.
Know however that even if $DISPLAY is always set, it will not always have the same value. At least for me, XQuartz has the annoying habit of increasing the display number after a restart.

If it's too complicated to remove all references to $DISPLAY from KDE code (which wouldn't surprise me at all) there remains another approach. Identify an appropriate location in the startup/initialisation code that all KDE applications and services share, and set $DISPLAY to something sensible (but preferably NOT a valid X11 display specifier). The only possible undesirable side-effect I can see from here would be that shells in konsole risk to inherit that value.
This probably isn't the most elegant solution, but then again that's because KDE apparently never imposed the use of its own internal variable/function (or one from Qt) instead of directly querying $DISPLAY.

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 07/29/2014 - 20:13

Perish the thought ($DISPLAY fluctuating between a value and an empty string). On my system, OS X 10.7.5 (Lion), XQuartz was installed by Apple and $DISPLAY is always set to a value, even if XQuartz (X11.app) is not running (i.e. no X11 server running). I presume installing X11 somehow "doctors" the OS X (Darwin) startup procedures so that DISPLAY is already defined in every user's ~/.profile. I do not know if that would be the case if a FOSS version of XQuartz would be installed (e.g. on OS X 10.9.x Mavericks).

The big thing is that $DISPLAY -is- used (non-portably) in KDE to help name a socket in kdeinit4 (kinit.cpp), wrapper.c, kwrapper and KCrash - and FAIK it may be used in this way in several other places. If $DISPLAY is not used consistently in all those places, communication with kdeinit4 can break, as it does already in KCrash/kdeinit4 on Apple OS X. And THAT is what we are trying to fix here. KDE apps on Apple OS X MUST be able to report a crash reliably.

This is why I keep asking for help from a KDE core developer. How widespread is this problem in KDE on Apple OS X? What are the implication for KDE apps? Should references to $DISPLAY in KDE be eliminated from the OS X version? What do kdeinit4, kwrapper and klauncher really do? Is whatever they do actually portable to Apple OS X? Or are we all, KDE guys and MacPorts guys alike, just crossing our fingers and hoping for the best?

I tried using lxr.kde.org to find further references, but there are thousands: mostly because "display" is a commonly-used English word in programming. And I did tick the case-sensitive box, but it does not seem to work.

- Ian

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/29/2014 - 11:14

Nope. It can be set if the user has XQuartz installed and running, but that shouldn't make a difference.

In fact, $DISPLAY shouldn't be used on OS X because we wouldn't want things like socket names change when the user starts or quits XQuartz with KDE apps and/or services running.

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 07/27/2014 - 19:57

kinit/kinit.cpp
<https://git.reviewboard.kde.org/r/119497/#comment44119>

The real issue is on this line. I do not know how "MAC_DISPLAY" got into the act, but clearly it has not been tested recently, if ever. There is no "MAC_DISPLAY" in Apple OS X.

Also "DISPLAY" is a threatened species in Mac OS X and its existence in an installation appears to depend, in more recent versions of Apple OS X, on whether FOSS XQuartz (a non-Apple X11 emulator) is installed.

It is not clear ATM whether the socket name on which kinit "listens" needs to be qualified in some way on Apple OS X, as opposed to Linux and X11, or whether $DISPLAY could safely have an empty string as its value.

Also, I find it questionable that kinit.cpp, wrapper.c and kcrash.cpp use different methods or cloned source-code to evaluate the all-important socket name on which they will communicate. See kdeui/util/kcrash.cpp line 637. There must be a better way to program this...

That is why I would like to see some KDE core developers reviewing this code. I am not a KDE core developer.

- Ian Wadham

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/14/2014 - 20:40

This part of the patch has been discontinued.

- Ian

On Sept. 15, 2014, 1:39 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 07/29/2014 - 02:23

Thank you, David, for taking the time to reply. I know you are always very busy.

So the easiest fix on Apple OS X (all versions) would be to use $DISPLAY whenever the socket name is computed and allow an empty string. I will modify this patch accordingly.

David, can you find a core developer from the Frameworks team to help me occasionally with advice, answers to technical questions and reviews?

I am really struggling with the KDE portability problems on Apple OS X and I am sure I could work many times faster with a little expert help. Michael Pyne has helped me a lot in the last week or two, but he has business commitments coming up.

- Ian

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/28/2014 - 05:17

Ah, yes, I do get something like that printed on the terminal - but since I'm a tcsh-addicted dinosaur I cannot simply copy/paste the suggestion and I've never yet bothered to figure out how to translate them. Easier to start x11vnc and connect to the main session :)

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By David Faure at 07/28/2014 - 04:07

(It should have, after dbus got support for autostarting session, but otherwise you can always do it by hand
eval `dbus-launch` ; kdeinit4 ; kmyapp
)

- David

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/28/2014 - 03:12

It doesn't, indeed, and OS X doesn't allow non-X11 apps to be started remotely.

(It doesn't really work for me on Linux either, launching a KDE app from an ssh-X session rarely if ever started a new dbus session for me ...)

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By David Faure at 07/28/2014 - 03:02

The reason we have $DISPLAY in the kdeinit socket name on X11, is to allow the same user to have more than one graphical session.
I don't mean two full KDE-workspace instances running (they'd overwrite config files), but it happened to me sometimes that I would use ssh -X from another machine, then start one app (which wasn't running in the main session).
What happens then is that another kdeinit4 starts, in that separate session (which has a separate dbus session). So it should all be separate from the main session, hence $DISPLAY.

AFAIK this use case doesn't apply to Mac, so it would be ok to have an empty string in there.

- David

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Thoma... at 07/27/2014 - 06:32

kdeui/util/kcrash.cpp
<https://git.reviewboard.kde.org/r/119497/#comment44047>

is libdispatch OSX only or is it also used on FreeBSD?

The question (more to Michael ;-) is whether unconditionally closing all FDs is acceptable in general (there's hell lot of Q_OS_* items, incl. Q_OS_HURD ;-) or the check should be inverted to

#ifdef Q_OS_LINUX

kinit/kinit.cpp
<https://git.reviewboard.kde.org/r/119497/#comment44048>

this looks fishy, because this should be related to the Window System, not the OS (ie. if you're running X11 on Darwin)

Proper check would likely be Q_WS_MAC (though ultimately Q_WS disappeared with Qt5 anyway)

kinit/kinit.cpp
<https://git.reviewboard.kde.org/r/119497/#comment44049>

this and line 1504 look like debug leftovers? or are they needed for extra logging?

- Thomas Lübking

On Juli 27, 2014, 9:15 vorm., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 09/15/2014 - 04:13

Just wondering without having looked at the code: to what extent is the closing of FDs related to objects being `delete`d immediately instead of through `deleteLater`?

- René J.V.

On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 09/14/2014 - 20:39

NOT closing FDs at this point has been made conditional on Q_OS_WIN or Q_OS_MAC. Others may make it unconditional on all platforms. It might be a safe thing to do...

This part of the patch has been discontinued.

- Ian

On Sept. 15, 2014, 1:39 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Michael Pyne at 08/04/2014 - 18:07

Yes, you're right. It seems in the only problematic case (a direct fork/exec to start drkonqi) that we already close FDs unconditionally. In that case I think don't closing the FDs from the crash handler adds any value (and I suppose, might even interfere in debugging once drkonqi can get a debugger attached), so it might be best to remove the feature from the default crash handler entirely. David, thoughts?

- Michael

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 08/03/2014 - 20:31

On Apple OS X it is Apple's COCOA library internals that have the problem FDs, not the app, and COCOA crashes internally if you close its FDs in the crash handler. We do not know what numbers those FDs have in any arbitrary app or run of an app, and I think there is intrinsically no way to know. We also do not know what FDs may have been created by internals of the KDE library, but they do not seem to mind being closed peremptorily.

I could put a setFlags call (conditional on Q_OS_MAC) a few lines earlier in the default crash-handler, but there does not seem to be much point in that.

It is quite safe to leave FDs open, because KCrash closes them all unconditionally on line 623 of kcrash.cpp (if it starts Dr K by forking), with the comment "We are in the child now. Close FDs unconditionally." Presumably, by that time, the COCOA library has had a chance to terminate its internals gracefully, because this time there is no secondary crash. Presumably also, if Dr K is started via kinit and klauncher, its FDs are all its own, but kinit is a very grey area for me.

- Ian

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Michael Pyne at 08/03/2014 - 19:13

Unfortunately closing all FDs is probably not acceptable *in general*, but in the context of a launching a crash handler in a crashed KDE GUI application, I don't see any reason why it would hurt, it's not as if the application itself is going to need the FD anymore as it's about to crash and has already run its emergency save function (and if the app does need it, they can either use their own crash function or use the documented KeepFD flag). Closing all FDs is a security and rlimit precaution in case Dr. Konqi gets started directly from the crashing proc instead of via kdeinit.

The check should probably remain on any POSIX-alike, in my opinion, as we wouldn't want Dr. Konqi on Mac OS X accidentally having access to a crashing application FDs if launched directly either.

- Michael

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/28/2014 - 03:07

Exactly. Whatever is decided, KDE will have to consider that OS X is a Unix without X11, one on which $DISPLAY is indeed undefined. I don't think XQuartz is going anywhere in a foreseeable future but it'd be more future-proof not to depend on its presence at all. And I think that means everything cannot be left to runtime platform determination; code that invokes X11 calls will have to be in/excluded at compile time.

Whether or not things are done in a way that allows building for Qt/X11 (if/whenever it becomes possible again) and/or for (Open)Darwin is a different question. (Darwin is the name of the underlying unixy OS, excluding all GUI stuff, a distinction from OS X (macx) that is clearly relevant here.)

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 07/27/2014 - 21:02

"Absolutely". I agree. I have XQuartz installed on my MacBook, but I have no idea whether that gives rise to $DISPLAY having a value for me or whether it is supported by OS X 10.7.5 (Lion) itself. AFAIK X11 is used only by some non-KDE FOSS software apps I have installed, such as Inkscape and Gimp.

Bear in mind that there has been an evolution of display handling in successive versions of OS X and that Macports supports versions of OS X earlier than Lion and up to the most recent release (Mavericks), and that Qt-Mac supports them too and (in turn) MacPorts supports KDE software on all of them. The Wikipedia articles on Aqua and XQuartz give some overview of this evolution.

$DISPLAY definitely evaluates to the empty string on Mavericks, unless you happen to have XQuartz installed. Marko found that on his development setup for KDE CI on Apple OS X (Mavericks).

FWIW Frameworks' kdeinit/kinit.cpp currently has Q_OS_MACX on line 121. Maybe somebody ran a script to change all Q_WS to Q_OS, but the "MACX" is not in the doco for Qt5's QtGlobal. There must be hidden support for it, as there is for Q_WS_MACX in Qt-Mac 4.8.

- Ian

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 07/27/2014 - 20:10

I was using them for diagnosing this portability bug in kinit, but I thought it would be best to leave them in as a safety measure, so that someone can see what happened in the event that my issue/question re line 119 (what to do about the usage of "DISPLAY" in Apple OS X) causes premature termination of kdeinit4 in the future in an Apple OS X environment.

- Ian

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Thoma... at 07/27/2014 - 19:23

It's likely not.
You'll rather have to check for QGuiApplication::platformName() there (at runtime)

I considered it "fishy" because it's "which item doesn't fit" and because you're actually testing for the wrong item (Darwin, that's like testing for Linux to use X11 features) what only works because
a) apparently Q_OS_MAC atm. implies Q_WS_MAC since building for X11 on Darwin is claimed to fail
b) X11 and OSX walk together here anyway

However, (b) and a comment of yours on bug #337140 , I found googling on the topic, actually makes me wonder whether $DISPLAY is/was only set for XQuartz and has no relevance for OSX itself, thus being absent with dropping XQuartz and therefore absolutely no reliable hook for socket name creation on OSX?

- Thomas

On Juli 27, 2014, 9:15 vorm., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By Ian Wadham at 07/27/2014 - 18:37

There is nothing "fishy" about this. As you say, there is no Q_WS in Qt 5, only Q_OS. And Q_WS_MACX is even more archaic. This change is meant to be forward compatible with Qt 5.

It is also meant as a hint to KDE developers to clean up the myriad references to Q_WS in KDE software when preparing KF 5, if not already done.

Discussions of X11, Window Systems and raster graphics are irrelevant here. Qt 4.8 on Mac OS X is called Qt-Mac 4.8 and it works directly with Apple's Aqua, Core Graphics and COCOA library, using intermixed Objective C and C++ code, thus giving Qt and KDE applications the same look and feel as other apps on the Apple OS X desktop, except perhaps when a KFileDialog appears - like feathers on a dog... :-) The only fly in the ointment is that Qt_Mac 4.8 did NOT adopt raster graphics as standard (apparently RG was not ready at the first Qt-Mac 4.8 release time). Hopefully Qt-Mac 5 will remedy that.

- Ian

On July 27, 2014, 9:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/27/2014 - 09:20

I probably should have made explicit that I was talking about OS X, not consider it obvious given the context of this RR O:-)

But yes, the latest qt4-X11 version in MacPorts is 4.4.3 . I've tried to trick the current version into building as if under Linux, but something in the build process must be too clever for that. Long story short, it appears to be impossible to build Qt4 for Darwin/X11.

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Thoma... at 07/27/2014 - 08:13

No, but I guess we're talking past each other a bit ;-)

So, you're actually saying Qt4 can no longer be built for a Darwin/X11 combination (since 4.4)?

- Thomas

On Juli 27, 2014, 9:15 vorm., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Ren=C... at 07/27/2014 - 08:11

On OS X? Are you kidding me?

- RJVB

On July 27, 2014, 11:15 a.m., Ian Wadham wrote:

Re: Review Request 119497: Report crashes of KDE apps in Apple O

By =?utf-8?Q?Thoma... at 07/27/2014 - 07:23

This has nothing to do with the graphicssystem (which was set default to raster with 4.8) - the windowsystem is still X11

- Thomas

On Juli 27, 2014, 9:15 vorm., Ian Wadham wrote: