subject:"Review Request 119498\: Report crashes of KDE apps in Apple OS X \(2\) \(fix drkonqi\)"

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-23 Thread Ian Wadham

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated Sept. 24, 2014, 12:59 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: kde-runtime

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. Three patches for Dr Konqi are
submitted in this review. Patches for KCrash and kdeinit4 are submitted in part
1 of this review, against kdelibs. I am still investigating the other two
problems in Dr Konqi - and there could be more than two...

In this review we have three portability problems:

1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window
of the app that has just crashed, so is effectively useless. This appears to be
because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an
app is started with the Apple OS X open command, it always appears on top.
The patch just raises the dialog box.

2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on
the last line. This appears to be an error in the algorithm used (i.e. also a
bug in Linux KDE), but the patch is treating it as an Apple OS X portability
problem for now.

3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not,
stops reporting the crash. On Apple OS X, cookies would be kept in another
browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror)
and cookie jar. IMHO, Dr K should report the crash no matter what, as long as
it can connect to bugs.kde.org and log in.

Diffs
-

drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e
drkonqi/reportassistantpages_bugzilla.cpp 86ca327

Diff: https://git.reviewboard.kde.org/r/119498/diff/

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 will
also exist in Dr Konqi for KF 5, but I am as yet unable to build or test
Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks
repositories. I am sure there are many more Apple OS X portability problems in
Dr Konqi and other KDE software.

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

With my patches, Dr Konqi on Apple OS X can generate a full crash report,
including the backtrace and the results of the dialog with the user. Sometimes,
however, it fails to submit the completed report to bugs.kde.org. This problem
is still under investigation.

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.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian Wadham

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-21 Thread Ian Wadham



 On Sept. 19, 2014, 10:16 a.m., Ben Cooksley wrote:
  Unless anyone has any objections in the next 24 hours, I think this can go 
  in as it makes Dr Konqi usable on another platform.
 
 Thomas Lübking wrote:
 +1 - Shit It ... from my side.
 
 Certainly no technical concerns remaining here - but i'm not the code 
 owner/maintainer either ;-)
 
 Thomas Lübking wrote:
 ... shit it ... =)
 i should really read what i type. and maybe get a new keyboard =)
 
 Marko Käning wrote:
 Happened to me as well at some time, Thomas. :-)
 Weird, since letters t and p lie quite far away from each other and 
 are even linked to seperate hands... ;-)
 ---
 Well, the problem with this RR - as well as its associated one - is that 
 the project's maintainer should also say Ship it!, right?

Well, AFAICS, there IS no maintainer (see git logs) and I am not prepared to 
spend time looking for one. This review has been open for nearly 2 months and 
nobody has stepped forward and said they are the maintainer. Also, Ben 
Cooksley's 24 hours were well and truly up (see above) and there were no 
objections to the patch, so I did the Ship It myself. :-)

Anyway, I will not be committing any code until Tuesday, early hours (UTC).


- Ian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66935
---


On Sept. 18, 2014, 10:57 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated Sept. 18, 2014, 10:57 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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 
 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
 Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
 repositories. I am sure there are many more Apple OS X

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-20 Thread Thomas Lübking



 On Sept. 18, 2014, 9:19 vorm., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)
 
 Ian Wadham wrote:
 I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
 setuid/setgid a security breach (it calls it setugid). It is part of new 
 security rules that came into OS X about 4 versions ago.
 
 The question is moot, because I am not attempting to run Dr Konqi via 
 kdeinit4 any more, only by forking (see review 119497).
 
 So I propose to settle the issue by removing the Q_OS_MAC condition. I 
 intend to leave in the comment, however, to remind me to do something at this 
 point if I ever get the help I have asked for with the many problems in 
 kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from 
 KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
 
 All the tests I did on this in July showed that the crashing app, 
 kdeinit4 and Dr Konqi were all running as the logged-in user and no actual 
 setting of uid or gid was needed. They would just set things to what they 
 were before. Also none of the executable files had any special permission 
 bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the 
 machine somehow.
 
 FWIW the Apple OS X console log said, back in July:
 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
 KCrash::defaultCrashHandler (1623294600)...
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
 crashRecursionCounter = 2
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name 
 = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 
 14165
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
 /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
 -psn_0_327760 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to 
 start 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
 kdeinit
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
 sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got 
 EXEC_NEW 
 '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' 
 from wrapper.
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: 
 preparing to launch 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is 
 running setugid(), which is not allowed.
 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 
 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running 
 setugid(), which is not allowed.
 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 
 14167 terminated.
 
 René J.V. Bertin wrote:
 Ian, do you think this could in any way be related to the fact that one 
 must do certain permissions-related things in order the be able to use a 
 non-Apple-provided debugger? (Which in turn might have something to do with 
 preventing too easy reverse-engineering and other hacker business?)
 
 Ian Wadham wrote:
 No. Dr K works fine if you start it by forking, including the uid/gid 
 stuff. And I am pretty sure MacPorts implements a way to provide access to 
 debuggers of all stripes. That came up on macports-dev list a few months ago.
 
 René J.V. Bertin wrote:
 Yes, it (MacPorts) does. But one that involves something like a 
 code-signing certificate, IIRC. In other words, it seems to be linked to the 
 executable. OTOH, Dr K launches a standalone debugger, so as long as that 
 application has the necessary permissions, all should be fine.
 
 Ian Wadham wrote:
 There have been no

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-20 Thread René J . V . Bertin



 On Sept. 18, 2014, 11:19 a.m., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)
 
 Ian Wadham wrote:
 I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
 setuid/setgid a security breach (it calls it setugid). It is part of new 
 security rules that came into OS X about 4 versions ago.
 
 The question is moot, because I am not attempting to run Dr Konqi via 
 kdeinit4 any more, only by forking (see review 119497).
 
 So I propose to settle the issue by removing the Q_OS_MAC condition. I 
 intend to leave in the comment, however, to remind me to do something at this 
 point if I ever get the help I have asked for with the many problems in 
 kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from 
 KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
 
 All the tests I did on this in July showed that the crashing app, 
 kdeinit4 and Dr Konqi were all running as the logged-in user and no actual 
 setting of uid or gid was needed. They would just set things to what they 
 were before. Also none of the executable files had any special permission 
 bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the 
 machine somehow.
 
 FWIW the Apple OS X console log said, back in July:
 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
 KCrash::defaultCrashHandler (1623294600)...
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
 crashRecursionCounter = 2
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name 
 = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 
 14165
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
 /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
 -psn_0_327760 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to 
 start 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
 kdeinit
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
 sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got 
 EXEC_NEW 
 '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' 
 from wrapper.
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: 
 preparing to launch 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is 
 running setugid(), which is not allowed.
 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 
 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running 
 setugid(), which is not allowed.
 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 
 14167 terminated.
 
 René J.V. Bertin wrote:
 Ian, do you think this could in any way be related to the fact that one 
 must do certain permissions-related things in order the be able to use a 
 non-Apple-provided debugger? (Which in turn might have something to do with 
 preventing too easy reverse-engineering and other hacker business?)
 
 Ian Wadham wrote:
 No. Dr K works fine if you start it by forking, including the uid/gid 
 stuff. And I am pretty sure MacPorts implements a way to provide access to 
 debuggers of all stripes. That came up on macports-dev list a few months ago.
 
 René J.V. Bertin wrote:
 Yes, it (MacPorts) does. But one that involves something like a 
 code-signing certificate, IIRC. In other words, it seems to be linked to the 
 executable. OTOH, Dr K launches a standalone debugger, so as long as that 
 application has the necessary permissions, all should be fine.
 
 Ian Wadham wrote:
 There have been no

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-20 Thread Thomas Lübking



 On Sept. 18, 2014, 9:19 vorm., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)
 
 Ian Wadham wrote:
 I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
 setuid/setgid a security breach (it calls it setugid). It is part of new 
 security rules that came into OS X about 4 versions ago.
 
 The question is moot, because I am not attempting to run Dr Konqi via 
 kdeinit4 any more, only by forking (see review 119497).
 
 So I propose to settle the issue by removing the Q_OS_MAC condition. I 
 intend to leave in the comment, however, to remind me to do something at this 
 point if I ever get the help I have asked for with the many problems in 
 kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from 
 KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
 
 All the tests I did on this in July showed that the crashing app, 
 kdeinit4 and Dr Konqi were all running as the logged-in user and no actual 
 setting of uid or gid was needed. They would just set things to what they 
 were before. Also none of the executable files had any special permission 
 bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the 
 machine somehow.
 
 FWIW the Apple OS X console log said, back in July:
 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
 KCrash::defaultCrashHandler (1623294600)...
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
 crashRecursionCounter = 2
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name 
 = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 
 14165
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
 /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
 -psn_0_327760 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to 
 start 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
 kdeinit
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
 sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got 
 EXEC_NEW 
 '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' 
 from wrapper.
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: 
 preparing to launch 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is 
 running setugid(), which is not allowed.
 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 
 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running 
 setugid(), which is not allowed.
 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 
 14167 terminated.
 
 René J.V. Bertin wrote:
 Ian, do you think this could in any way be related to the fact that one 
 must do certain permissions-related things in order the be able to use a 
 non-Apple-provided debugger? (Which in turn might have something to do with 
 preventing too easy reverse-engineering and other hacker business?)
 
 Ian Wadham wrote:
 No. Dr K works fine if you start it by forking, including the uid/gid 
 stuff. And I am pretty sure MacPorts implements a way to provide access to 
 debuggers of all stripes. That came up on macports-dev list a few months ago.
 
 René J.V. Bertin wrote:
 Yes, it (MacPorts) does. But one that involves something like a 
 code-signing certificate, IIRC. In other words, it seems to be linked to the 
 executable. OTOH, Dr K launches a standalone debugger, so as long as that 
 application has the necessary permissions, all should be fine.
 
 Ian Wadham wrote:
 There have been no

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-20 Thread Thomas Lübking

On Sept. 19, 2014, 10:16 vorm., Ben Cooksley wrote:
Unless anyone has any objections in the next 24 hours, I think this can go
in as it makes Dr Konqi usable on another platform.

+1 - Shit It ... from my side.

Certainly no technical concerns remaining here - but i'm not the code
owner/maintainer either ;-)

- Thomas

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66935
---

On Sept. 18, 2014, 10:57 vorm., Ian Wadham wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated Sept. 18, 2014, 10:57 vorm.)

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

Repository: kde-runtime

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. Three patches for Dr Konqi are
submitted in this review. Patches for KCrash and kdeinit4 are submitted in
part 1 of this review, against kdelibs. I am still investigating the other
two problems in Dr Konqi - and there could be more than two...

In this review we have three portability problems:

1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main
window of the app that has just crashed, so is effectively useless. This
appears to be because Dr Konqi is started by a Linux/Unix method (fork() +
exec()?). If an app is started with the Apple OS X open command, it always
appears on top. The patch just raises the dialog box.

3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if
not, stops reporting the crash. On Apple OS X, cookies would be kept in
another browser (e.g. Safari or Firefox) and not in KDE's default browser
(Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter
what, as long as it can connect to bugs.kde.org and log in.

Diffs
-

drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e
drkonqi/reportassistantpages_bugzilla.cpp 86ca327

Diff: https://git.reviewboard.kde.org/r/119498/diff/

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
will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test
Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks
repositories. I am sure there are many more Apple OS X portability problems
in Dr Konqi and other KDE software.

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

With my patches, Dr Konqi on Apple OS X can generate a full crash report,
including the backtrace and the results of the dialog with the user.
Sometimes, however, it fails to submit the completed report to bugs.kde.org.
This problem is still under investigation.

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.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-20 Thread Ian Wadham

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review67098
---

Ship it!

Ship It!

- Ian Wadham

On Sept. 18, 2014, 10:57 a.m., Ian Wadham wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated Sept. 18, 2014, 10:57 a.m.)

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

Repository: kde-runtime

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. Three patches for Dr Konqi are
submitted in this review. Patches for KCrash and kdeinit4 are submitted in
part 1 of this review, against kdelibs. I am still investigating the other
two problems in Dr Konqi - and there could be more than two...

In this review we have three portability problems:

1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main
window of the app that has just crashed, so is effectively useless. This
appears to be because Dr Konqi is started by a Linux/Unix method (fork() +
exec()?). If an app is started with the Apple OS X open command, it always
appears on top. The patch just raises the dialog box.

3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if
not, stops reporting the crash. On Apple OS X, cookies would be kept in
another browser (e.g. Safari or Firefox) and not in KDE's default browser
(Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter
what, as long as it can connect to bugs.kde.org and log in.

Diffs
-

drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e
drkonqi/reportassistantpages_bugzilla.cpp 86ca327

Diff: https://git.reviewboard.kde.org/r/119498/diff/

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
will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test
Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks
repositories. I am sure there are many more Apple OS X portability problems
in Dr Konqi and other KDE software.

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

With my patches, Dr Konqi on Apple OS X can generate a full crash report,
including the backtrace and the results of the dialog with the user.
Sometimes, however, it fails to submit the completed report to bugs.kde.org.
This problem is still under investigation.

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.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian Wadham

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-19 Thread Ben Cooksley

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66935
---

Unless anyone has any objections in the next 24 hours, I think this can go in
as it makes Dr Konqi usable on another platform.

- Ben Cooksley

On Sept. 18, 2014, 10:57 a.m., Ian Wadham wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated Sept. 18, 2014, 10:57 a.m.)

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

Repository: kde-runtime

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. Three patches for Dr Konqi are
submitted in this review. Patches for KCrash and kdeinit4 are submitted in
part 1 of this review, against kdelibs. I am still investigating the other
two problems in Dr Konqi - and there could be more than two...

In this review we have three portability problems:

1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main
window of the app that has just crashed, so is effectively useless. This
appears to be because Dr Konqi is started by a Linux/Unix method (fork() +
exec()?). If an app is started with the Apple OS X open command, it always
appears on top. The patch just raises the dialog box.

3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if
not, stops reporting the crash. On Apple OS X, cookies would be kept in
another browser (e.g. Safari or Firefox) and not in KDE's default browser
(Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter
what, as long as it can connect to bugs.kde.org and log in.

Diffs
-

drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e
drkonqi/reportassistantpages_bugzilla.cpp 86ca327

Diff: https://git.reviewboard.kde.org/r/119498/diff/

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
will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test
Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks
repositories. I am sure there are many more Apple OS X portability problems
in Dr Konqi and other KDE software.

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

With my patches, Dr Konqi on Apple OS X can generate a full crash report,
including the backtrace and the results of the dialog with the user.
Sometimes, however, it fails to submit the completed report to bugs.kde.org.
This problem is still under investigation.

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.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian Wadham

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-19 Thread Thomas Lübking



 On Sept. 18, 2014, 9:19 vorm., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)
 
 Ian Wadham wrote:
 I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
 setuid/setgid a security breach (it calls it setugid). It is part of new 
 security rules that came into OS X about 4 versions ago.
 
 The question is moot, because I am not attempting to run Dr Konqi via 
 kdeinit4 any more, only by forking (see review 119497).
 
 So I propose to settle the issue by removing the Q_OS_MAC condition. I 
 intend to leave in the comment, however, to remind me to do something at this 
 point if I ever get the help I have asked for with the many problems in 
 kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from 
 KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
 
 All the tests I did on this in July showed that the crashing app, 
 kdeinit4 and Dr Konqi were all running as the logged-in user and no actual 
 setting of uid or gid was needed. They would just set things to what they 
 were before. Also none of the executable files had any special permission 
 bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the 
 machine somehow.
 
 FWIW the Apple OS X console log said, back in July:
 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
 KCrash::defaultCrashHandler (1623294600)...
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
 crashRecursionCounter = 2
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name 
 = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 
 14165
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
 /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
 -psn_0_327760 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to 
 start 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
 kdeinit
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
 sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got 
 EXEC_NEW 
 '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' 
 from wrapper.
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: 
 preparing to launch 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is 
 running setugid(), which is not allowed.
 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 
 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running 
 setugid(), which is not allowed.
 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 
 14167 terminated.
 
 René J.V. Bertin wrote:
 Ian, do you think this could in any way be related to the fact that one 
 must do certain permissions-related things in order the be able to use a 
 non-Apple-provided debugger? (Which in turn might have something to do with 
 preventing too easy reverse-engineering and other hacker business?)
 
 Ian Wadham wrote:
 No. Dr K works fine if you start it by forking, including the uid/gid 
 stuff. And I am pretty sure MacPorts implements a way to provide access to 
 debuggers of all stripes. That came up on macports-dev list a few months ago.
 
 René J.V. Bertin wrote:
 Yes, it (MacPorts) does. But one that involves something like a 
 code-signing certificate, IIRC. In other words, it seems to be linked to the 
 executable. OTOH, Dr K launches a standalone debugger, so as long as that 
 application has the necessary permissions, all should be fine.
 
 Ian Wadham wrote:
 There have been no

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-19 Thread Ian Wadham



 On Sept. 18, 2014, 9:19 a.m., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)
 
 Ian Wadham wrote:
 I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
 setuid/setgid a security breach (it calls it setugid). It is part of new 
 security rules that came into OS X about 4 versions ago.
 
 The question is moot, because I am not attempting to run Dr Konqi via 
 kdeinit4 any more, only by forking (see review 119497).
 
 So I propose to settle the issue by removing the Q_OS_MAC condition. I 
 intend to leave in the comment, however, to remind me to do something at this 
 point if I ever get the help I have asked for with the many problems in 
 kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from 
 KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
 
 All the tests I did on this in July showed that the crashing app, 
 kdeinit4 and Dr Konqi were all running as the logged-in user and no actual 
 setting of uid or gid was needed. They would just set things to what they 
 were before. Also none of the executable files had any special permission 
 bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the 
 machine somehow.
 
 FWIW the Apple OS X console log said, back in July:
 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
 KCrash::defaultCrashHandler (1623294600)...
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
 crashRecursionCounter = 2
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name 
 = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 
 14165
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
 /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
 -psn_0_327760 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to 
 start 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
 kdeinit
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
 sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got 
 EXEC_NEW 
 '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' 
 from wrapper.
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: 
 preparing to launch 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is 
 running setugid(), which is not allowed.
 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 
 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running 
 setugid(), which is not allowed.
 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 
 14167 terminated.
 
 René J.V. Bertin wrote:
 Ian, do you think this could in any way be related to the fact that one 
 must do certain permissions-related things in order the be able to use a 
 non-Apple-provided debugger? (Which in turn might have something to do with 
 preventing too easy reverse-engineering and other hacker business?)
 
 Ian Wadham wrote:
 No. Dr K works fine if you start it by forking, including the uid/gid 
 stuff. And I am pretty sure MacPorts implements a way to provide access to 
 debuggers of all stripes. That came up on macports-dev list a few months ago.
 
 René J.V. Bertin wrote:
 Yes, it (MacPorts) does. But one that involves something like a 
 code-signing certificate, IIRC. In other words, it seems to be linked to the 
 executable. OTOH, Dr K launches a standalone debugger, so as long as that 
 application has the necessary permissions, all should be fine.
 
 Ian Wadham wrote:
 There have been no

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-18 Thread Thomas Lübking


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66817
---



drkonqi/main.cpp
https://git.reviewboard.kde.org/r/119498/#comment46598

this sounds fishy - at least the comment to be incorrect?
i hope that OSX does not just actually abort() when you call setuid() but 
that indeed the tests fail and the applications exits(255)?

In case of the latter, does the process itself run with suid until this 
point?

I assume if we've to consider that drkonqi does not (require) to run suid, 
the test should be omitted if geteuid() (notice the e!) isn't 0.

Skipping this altogether only makes sense for broken by design operating 
systems which fail to confirm to posix standards (windows ;-)


- Thomas Lübking


On Sept. 16, 2014, 11:08 vorm., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated Sept. 16, 2014, 11:08 vorm.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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 
 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
 Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
 repositories. I am sure there are many more Apple OS X portability problems 
 in Dr Konqi and other KDE software.
 
 Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, 
 often fails to complete the backtrace report and then fails to connect to 
 bugs.kde.org.
 
 With my patches, Dr Konqi on Apple OS X can generate a full crash report, 
 including the backtrace and the results of the dialog with the user. 
 Sometimes, however, it fails to submit the completed report to bugs.kde.org. 
 This problem is still under investigation.
 
 I would not have got this far without help from Michael Pyne, Thomas Lübking

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-18 Thread Ian Wadham



 On Sept. 18, 2014, 9:19 a.m., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)

I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
setuid/setgid a security breach (it calls it setugid). It is part of new 
security rules that came into OS X about 4 versions ago.

The question is moot, because I am not attempting to run Dr Konqi via kdeinit4 
any more, only by forking (see review 119497).

So I propose to settle the issue by removing the Q_OS_MAC condition. I intend 
to leave in the comment, however, to remind me to do something at this point if 
I ever get the help I have asked for with the many problems in kdeinit4 and 
friends on Apple OS X, or if the methods of running Dr K from KCrash change in 
KF5. I heard a rumour that kdeinit is to be dropped in KF5.

All the tests I did on this in July showed that the crashing app, kdeinit4 and 
Dr Konqi were all running as the logged-in user and no actual setting of uid or 
gid was needed. They would just set things to what they were before. Also none 
of the executable files had any special permission bits set. Nevertheless, a 
few lines later, Apple OS X kicks Dr Konqi off the machine somehow.

FWIW the Apple OS X console log said, back in July:

22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
KCrash::defaultCrashHandler (1623294600)...
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
crashRecursionCounter = 2
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name = 
palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 14165
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
/Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
-psn_0_327760 
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to start 
/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
kdeinit
22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got EXEC_NEW 
'/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' from 
wrapper.
22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: preparing to 
launch /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 
0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in place - just 
leaking - break on objc_autoreleaseNoPool() to debug
22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: Object 
0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in place - just 
leaking - break on objc_autoreleaseNoPool() to debug
22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is running 
setugid(), which is not allowed.
22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 16:30:34.545 
drkonqi[14167:2503] The application with bundle ID  is running setugid(), which 
is not allowed.
22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 14167 
terminated.


- Ian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66817
---


On Sept. 16, 2014, 11:08 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated Sept. 16, 2014, 11:08 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-18 Thread Ian Wadham

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated Sept. 18, 2014, 10:57 a.m.)

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

Changes
---

Removed the Q_OS_MAC condition for bypassing setuid/setgid in main(). The
comments remain as a reminder for when kdeinit4 or some other process can be
used to start Dr Konqi, instead of just forking.

Repository: kde-runtime

Description
---

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

In this review we have three portability problems:

Diffs (updated)
-

drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e
drkonqi/reportassistantpages_bugzilla.cpp 86ca327

Diff: https://git.reviewboard.kde.org/r/119498/diff/

Testing
---

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

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.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian Wadham

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-18 Thread René J . V . Bertin



 On Sept. 18, 2014, 11:19 a.m., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)
 
 Ian Wadham wrote:
 I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
 setuid/setgid a security breach (it calls it setugid). It is part of new 
 security rules that came into OS X about 4 versions ago.
 
 The question is moot, because I am not attempting to run Dr Konqi via 
 kdeinit4 any more, only by forking (see review 119497).
 
 So I propose to settle the issue by removing the Q_OS_MAC condition. I 
 intend to leave in the comment, however, to remind me to do something at this 
 point if I ever get the help I have asked for with the many problems in 
 kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from 
 KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
 
 All the tests I did on this in July showed that the crashing app, 
 kdeinit4 and Dr Konqi were all running as the logged-in user and no actual 
 setting of uid or gid was needed. They would just set things to what they 
 were before. Also none of the executable files had any special permission 
 bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the 
 machine somehow.
 
 FWIW the Apple OS X console log said, back in July:
 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
 KCrash::defaultCrashHandler (1623294600)...
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
 crashRecursionCounter = 2
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name 
 = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 
 14165
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
 /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
 -psn_0_327760 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to 
 start 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
 kdeinit
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
 sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got 
 EXEC_NEW 
 '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' 
 from wrapper.
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: 
 preparing to launch 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is 
 running setugid(), which is not allowed.
 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 
 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running 
 setugid(), which is not allowed.
 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 
 14167 terminated.

Ian, do you think this could in any way be related to the fact that one must do 
certain permissions-related things in order the be able to use a 
non-Apple-provided debugger? (Which in turn might have something to do with 
preventing too easy reverse-engineering and other hacker business?)


- René J.V.


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66817
---


On Sept. 18, 2014, 12:57 p.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated Sept. 18, 2014, 12:57 p.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-18 Thread René J . V . Bertin



 On Sept. 18, 2014, 11:19 a.m., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)
 
 Ian Wadham wrote:
 I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
 setuid/setgid a security breach (it calls it setugid). It is part of new 
 security rules that came into OS X about 4 versions ago.
 
 The question is moot, because I am not attempting to run Dr Konqi via 
 kdeinit4 any more, only by forking (see review 119497).
 
 So I propose to settle the issue by removing the Q_OS_MAC condition. I 
 intend to leave in the comment, however, to remind me to do something at this 
 point if I ever get the help I have asked for with the many problems in 
 kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from 
 KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
 
 All the tests I did on this in July showed that the crashing app, 
 kdeinit4 and Dr Konqi were all running as the logged-in user and no actual 
 setting of uid or gid was needed. They would just set things to what they 
 were before. Also none of the executable files had any special permission 
 bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the 
 machine somehow.
 
 FWIW the Apple OS X console log said, back in July:
 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
 KCrash::defaultCrashHandler (1623294600)...
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
 crashRecursionCounter = 2
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name 
 = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 
 14165
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
 /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
 -psn_0_327760 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to 
 start 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
 kdeinit
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
 sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got 
 EXEC_NEW 
 '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' 
 from wrapper.
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: 
 preparing to launch 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is 
 running setugid(), which is not allowed.
 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 
 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running 
 setugid(), which is not allowed.
 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 
 14167 terminated.
 
 René J.V. Bertin wrote:
 Ian, do you think this could in any way be related to the fact that one 
 must do certain permissions-related things in order the be able to use a 
 non-Apple-provided debugger? (Which in turn might have something to do with 
 preventing too easy reverse-engineering and other hacker business?)
 
 Ian Wadham wrote:
 No. Dr K works fine if you start it by forking, including the uid/gid 
 stuff. And I am pretty sure MacPorts implements a way to provide access to 
 debuggers of all stripes. That came up on macports-dev list a few months ago.

Yes, it (MacPorts) does. But one that involves something like a code-signing 
certificate, IIRC. In other words, it seems to be linked to the executable. 
OTOH, Dr K launches a standalone debugger, so as long as that application has 
the necessary permissions, all should be fine.


- René J.V.


---

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-18 Thread Ian Wadham



 On Sept. 18, 2014, 9:19 a.m., Thomas Lübking wrote:
  drkonqi/main.cpp, line 47
  https://git.reviewboard.kde.org/r/119498/diff/2/?file=312509#file312509line47
 
  this sounds fishy - at least the comment to be incorrect?
  i hope that OSX does not just actually abort() when you call setuid() 
  but that indeed the tests fail and the applications exits(255)?
  
  In case of the latter, does the process itself run with suid until this 
  point?
  
  I assume if we've to consider that drkonqi does not (require) to run 
  suid, the test should be omitted if geteuid() (notice the e!) isn't 0.
  
  Skipping this altogether only makes sense for broken by design 
  operating systems which fail to confirm to posix standards (windows ;-)
 
 Ian Wadham wrote:
 I am pretty sure Apple OS X does just abort Dr Konqi. It considers use of 
 setuid/setgid a security breach (it calls it setugid). It is part of new 
 security rules that came into OS X about 4 versions ago.
 
 The question is moot, because I am not attempting to run Dr Konqi via 
 kdeinit4 any more, only by forking (see review 119497).
 
 So I propose to settle the issue by removing the Q_OS_MAC condition. I 
 intend to leave in the comment, however, to remind me to do something at this 
 point if I ever get the help I have asked for with the many problems in 
 kdeinit4 and friends on Apple OS X, or if the methods of running Dr K from 
 KCrash change in KF5. I heard a rumour that kdeinit is to be dropped in KF5.
 
 All the tests I did on this in July showed that the crashing app, 
 kdeinit4 and Dr Konqi were all running as the logged-in user and no actual 
 setting of uid or gid was needed. They would just set things to what they 
 were before. Also none of the executable files had any special permission 
 bits set. Nevertheless, a few lines later, Apple OS X kicks Dr Konqi off the 
 machine somehow.
 
 FWIW the Apple OS X console log said, back in July:
 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: ENTERING 
 KCrash::defaultCrashHandler (1623294600)...
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: crashing... 
 crashRecursionCounter = 2
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Application Name 
 = palapeli path = /Applications/kde4.13/palapeli.app/Contents/MacOS pid = 
 14165
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Arguments: 
 /Applications/kde4.13/palapeli.app/Contents/MacOS/palapeli --nocrashhandler 
 -psn_0_327760 
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: KCrash: Attempting to 
 start 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from 
 kdeinit
 22/07/14 4:30:34.451 PM [0x0-0x50050].palapeli: Connect 
 sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-KdDfgS_org.x_0
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: Got 
 EXEC_NEW 
 '/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi' 
 from wrapper.
 22/07/14 4:30:34.451 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: 
 preparing to launch 
 /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e5e0 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.545 PM [0x0-0x4f04f].org.kde.kdeinit4: objc[14167]: 
 Object 0x7fc6cb64e660 of class NSPathStore2 autoreleased with no pool in 
 place - just leaking - break on objc_autoreleaseNoPool() to debug
 22/07/14 4:30:34.546 PM drkonqi: The application with bundle ID  is 
 running setugid(), which is not allowed.
 22/07/14 4:30:34.546 PM [0x0-0x4f04f].org.kde.kdeinit4: 2014-07-22 
 16:30:34.545 drkonqi[14167:2503] The application with bundle ID  is running 
 setugid(), which is not allowed.
 22/07/14 4:30:34.549 PM [0x0-0x4f04f].org.kde.kdeinit4: kdeinit4: PID 
 14167 terminated.
 
 René J.V. Bertin wrote:
 Ian, do you think this could in any way be related to the fact that one 
 must do certain permissions-related things in order the be able to use a 
 non-Apple-provided debugger? (Which in turn might have something to do with 
 preventing too easy reverse-engineering and other hacker business?)
 
 Ian Wadham wrote:
 No. Dr K works fine if you start it by forking, including the uid/gid 
 stuff. And I am pretty sure MacPorts implements a way to provide access to 
 debuggers of all stripes. That came up on macports-dev list a few months ago.
 
 René J.V. Bertin wrote:
 Yes, it (MacPorts) does. But one that involves something like a 
 code-signing certificate, IIRC. In other words, it seems to be linked to the 
 executable. OTOH, Dr K launches a standalone debugger, so as long as that 
 application has the necessary permissions, all should be fine.

There have been no problems with hooking up

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-17 Thread Ian Wadham


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66801
---


Please would someone give this a Ship It, or should I do it myself?

I need to ship this patch and the accompanying 119497 patch simultaneously 
(they are inter-dependent and 119497 already has a Ship It).

Also I need to get on with further work on Dr Konqi to bring its security-code 
up-to-date with bugs.kde.org and the current Bugzilla software version.

All of this work will have benefits in Frameworks/KF5 as well as KDE 4.

- Ian Wadham


On Sept. 16, 2014, 11:08 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated Sept. 16, 2014, 11:08 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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 
 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
 Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
 repositories. I am sure there are many more Apple OS X portability problems 
 in Dr Konqi and other KDE software.
 
 Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, 
 often fails to complete the backtrace report and then fails to connect to 
 bugs.kde.org.
 
 With my patches, Dr Konqi on Apple OS X can generate a full crash report, 
 including the backtrace and the results of the dialog with the user. 
 Sometimes, however, it fails to submit the completed report to bugs.kde.org. 
 This problem is still under investigation.
 
 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.
 
 
 File Attachments
 
 
 Log of Dr K ASSERT problem

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-16 Thread Ian Wadham

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated Sept. 16, 2014, 10:49 a.m.)

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

Repository: kde-runtime

Description
---

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

In this review we have three portability problems:

Diffs (updated)
-

drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e
drkonqi/reportassistantpages_bugzilla.cpp 86ca327

Diff: https://git.reviewboard.kde.org/r/119498/diff/

Testing
---

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

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.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian Wadham

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-16 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
 

This part of the patch, to fix the bug in the backtrace lines highlighter, has 
been re-written as suggested by Thomas, by adding a dummy entry to the lines, 
and the ASSERT remains because we should never get past the dummy, however many 
'\n' characters are in the last entry in the backtrace.


 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/main.cpp, line 111
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293511#file293511line111
 
  This can go unconditionally.
  
  Show really only shows the window.
  Becoming active and then raise for that is WM detail - and WMs have to 
  deal with inadequate raise requests anyway ;-)
 
 Ian Wadham wrote:
 I do not understand your comments at all.
 
 I just know that the raise() is essential in this context, otherwise the 
 end-user never sees Dr Konqi's window and never investigates or reports the 
 crash.
 
 On Apple OS X, an app which is started properly, by clicking an icon or 
 running an Apple OS X open command, will raise the app's window, but Dr 
 Konqi is not being started this way.
 
 Thomas Lübking wrote:
 You can omit the system test.
 It's ok to call raise() here on any system.

For safety, raise() will be used on all platforms and window managers, making 
sure the Dr Konqi dialog is always visible.


 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 286
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line286
 
  #ifndef
 
 Ian Wadham wrote:
 No, #ifdef. The lines following 286 apply to Apple OS X and nothing else. 
 ATM they are only explanatory. But there is a place to add code if anybody 
 can think of something appropriate (e.g. to check for cookies on the user's 
 browser of choice in a portable way, maybe using Qt).
 
 René J.V. Bertin wrote:
 Probably not relevant here at all, but mentioning a place to add 
 appropriate code for this kind of thing reminds me of the fact that browser 
 plugins are organised in a quite different way on OS X, and it would be great 
 if konqueror could pick them up. Just sayin', for the record :)
 
 Thomas Lübking wrote:
 I meant to use an #ifndef (and reverse the logic of course) because some 
 #else branch is actually not required - unless of course you indeed want to 
 add some apple specific code.

The cookie-checking code will be bypassed on Apple OS X for now, because it can 
cause Dr Konqi to crash. It is intended that it will be replaced by code to 
handle the new token-checking policy of Bugzilla 4.4.3 and later (4.4.5 on 
bugs.kde.org).


 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.
 
 Aaron J. Seigo wrote:
 The login relies on cookies so the check must stAy. The check should 
 remain osx in case in future this works. However what should probably happen 
 is the Login button and text fields should be disabled pendiNg a call to see 
 if cookies are enabled. That check should made async and the message boxes 
 removed in favour oof inline messages Incliding A link to tirn cookies on 
 instead of a yes/no dialog.
 Sorry for the typos. This form barel works at all with the android web 
 browser :(
 miAnimizin
 
 Ian Wadham wrote:
 The login works OK, cookies or not. Dr K asks you to enter user name and 
 password every time, regardless of whether you are already logged in and have 
 cookies. In my case, the cookies are in Firefox in whatever location it uses 
 with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able 
 to. I have tried (briefly) going the KDE way, using Konqueror and defining it 
 (to KDE preferences) as my preferred browser and then logging in to BKO with 
 Konqueror, but on Apple OS X that is cumbersome to set up and does not work 
 predictably in Dr K, as it must if we want the average user to report bugs.
 
 After the login, it was possible to report a bug completely 
 https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie 
 check enabled one cannot report anything, because Dr K crashes in the middle 
 of

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-16 Thread Ian Wadham

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated Sept. 16, 2014, 11:08 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: kde-runtime

Description
---

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

In this review we have three portability problems:

Diffs
-

drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e
drkonqi/reportassistantpages_bugzilla.cpp 86ca327

Diff: https://git.reviewboard.kde.org/r/119498/diff/

Testing
---

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

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.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian Wadham

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-15 Thread Marko Käning

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66626
---

And this should be marked as depending on RR 119497 in Depends On.

- Marko Käning

On July 30, 2014, 3:04 p.m., Ian Wadham wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated July 30, 2014, 3:04 p.m.)

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

Repository: kde-runtime

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. Three patches for Dr Konqi are
submitted in this review. Patches for KCrash and kdeinit4 are submitted in
part 1 of this review, against kdelibs. I am still investigating the other
two problems in Dr Konqi - and there could be more than two...

In this review we have three portability problems:

1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main
window of the app that has just crashed, so is effectively useless. This
appears to be because Dr Konqi is started by a Linux/Unix method (fork() +
exec()?). If an app is started with the Apple OS X open command, it always
appears on top. The patch just raises the dialog box.

3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if
not, stops reporting the crash. On Apple OS X, cookies would be kept in
another browser (e.g. Safari or Firefox) and not in KDE's default browser
(Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter
what, as long as it can connect to bugs.kde.org and log in.

Diffs
-

drkonqi/reportassistantpages_bugzilla.cpp 86ca327
drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e

Diff: https://git.reviewboard.kde.org/r/119498/diff/

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
will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test
Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks
repositories. I am sure there are many more Apple OS X portability problems
in Dr Konqi and other KDE software.

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

With my patches, Dr Konqi on Apple OS X can generate a full crash report,
including the backtrace and the results of the dialog with the user.
Sometimes, however, it fails to submit the completed report to bugs.kde.org.
This problem is still under investigation.

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.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian Wadham

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-08-04 Thread Ben Cooksley



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.
 
 Aaron J. Seigo wrote:
 The login relies on cookies so the check must stAy. The check should 
 remain osx in case in future this works. However what should probably happen 
 is the Login button and text fields should be disabled pendiNg a call to see 
 if cookies are enabled. That check should made async and the message boxes 
 removed in favour oof inline messages Incliding A link to tirn cookies on 
 instead of a yes/no dialog.
 Sorry for the typos. This form barel works at all with the android web 
 browser :(
 miAnimizin
 
 Ian Wadham wrote:
 The login works OK, cookies or not. Dr K asks you to enter user name and 
 password every time, regardless of whether you are already logged in and have 
 cookies. In my case, the cookies are in Firefox in whatever location it uses 
 with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able 
 to. I have tried (briefly) going the KDE way, using Konqueror and defining it 
 (to KDE preferences) as my preferred browser and then logging in to BKO with 
 Konqueror, but on Apple OS X that is cumbersome to set up and does not work 
 predictably in Dr K, as it must if we want the average user to report bugs.
 
 After the login, it was possible to report a bug completely 
 https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie 
 check enabled one cannot report anything, because Dr K crashes in the middle 
 of the cookie check (on Apple OS X).
 
 Dr K uses remote procedure calls to do its work on BKO (class 
 KXmlRpc::Client), including logging in. See code in 
 kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K 
 could somehow connect to BKO via the user's browser of choice or cookies 
 therein, using something really portable, similar to 
 QDesktopServices::openUrl(), but I cannot see any immediate way to do that.
 
 I have another bug, not yet investigated in detail, where Dr K has lost 
 the login to BKO somehow and cannot submit the completed report, but it was 
 still able to save it in a file.
 
 It is hard to know how to test Dr K's bug-report submission thoroughly 
 without cluttering up BKO with irrelevant reports. Is there a test version of 
 the BKO database somewhere?
 
 Ben Cooksley wrote:
 The use of the Bugzilla XMLRPC api is required i'm afraid. The web 
 browser interface cannot be used - due to CSRF protections now built into it. 
 In addition, it changes from time to time breaking compatability. This form 
 of HTML scraping was used by prior versions of Dr Konqi - and broke quite 
 badly when Bugzilla was upgraded to 4.2.x.
 
 Ian Wadham wrote:
 @Ben Cooksley: Understood. I was thinking more along the lines of 
 connecting without starting a browser window (which would be a nuisance for 
 the user anyway), but somehow using the cookies that might have been stored 
 by the user's browser of choice, and if that fails THEN ask for username and 
 password. Our problem, on Apple OS X, is that none of Dr K works ATM if your 
 browser of choice is Safari or Firefox or even Konqueror, because the cookies 
 are stored somewhere that is not the KCookieJar. Maybe the Qt guys solved 
 this problem somewhere, e.g. when developing QDesktopServices::openUrl(). Of 
 course, Dr K must still use KXmlRpc::Client for data transfer to and fro.
 
 RJVB Bertin wrote:
 ? Maybe it's because I have Chrome as my default browser, but Konqueror 
 uses the kcookiejar over here. If I make sure kded4 is running, that is; 
 otherwise it can't.
 I do have a bit of a hard time believing that someone tweaked things so 
 that KDE would use the native cookie store but  as a function of which 
 browser you have configured as a default. (If I'd have to chose I'd say that 
 support for native plugins is a tad more useful!)
 
 Ben Cooksley wrote:
 Unfortunately Bugzilla has removed support for using cookies to submit 
 XMLRPC API queries in version 4.4, in favour of access tokens so it isn't 
 possible to do that either i'm afraid :(
 
 Ian Wadham wrote:
 It seems that bugs.kde.org has changed to using

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-08-04 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.
 
 Aaron J. Seigo wrote:
 The login relies on cookies so the check must stAy. The check should 
 remain osx in case in future this works. However what should probably happen 
 is the Login button and text fields should be disabled pendiNg a call to see 
 if cookies are enabled. That check should made async and the message boxes 
 removed in favour oof inline messages Incliding A link to tirn cookies on 
 instead of a yes/no dialog.
 Sorry for the typos. This form barel works at all with the android web 
 browser :(
 miAnimizin
 
 Ian Wadham wrote:
 The login works OK, cookies or not. Dr K asks you to enter user name and 
 password every time, regardless of whether you are already logged in and have 
 cookies. In my case, the cookies are in Firefox in whatever location it uses 
 with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able 
 to. I have tried (briefly) going the KDE way, using Konqueror and defining it 
 (to KDE preferences) as my preferred browser and then logging in to BKO with 
 Konqueror, but on Apple OS X that is cumbersome to set up and does not work 
 predictably in Dr K, as it must if we want the average user to report bugs.
 
 After the login, it was possible to report a bug completely 
 https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie 
 check enabled one cannot report anything, because Dr K crashes in the middle 
 of the cookie check (on Apple OS X).
 
 Dr K uses remote procedure calls to do its work on BKO (class 
 KXmlRpc::Client), including logging in. See code in 
 kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K 
 could somehow connect to BKO via the user's browser of choice or cookies 
 therein, using something really portable, similar to 
 QDesktopServices::openUrl(), but I cannot see any immediate way to do that.
 
 I have another bug, not yet investigated in detail, where Dr K has lost 
 the login to BKO somehow and cannot submit the completed report, but it was 
 still able to save it in a file.
 
 It is hard to know how to test Dr K's bug-report submission thoroughly 
 without cluttering up BKO with irrelevant reports. Is there a test version of 
 the BKO database somewhere?
 
 Ben Cooksley wrote:
 The use of the Bugzilla XMLRPC api is required i'm afraid. The web 
 browser interface cannot be used - due to CSRF protections now built into it. 
 In addition, it changes from time to time breaking compatability. This form 
 of HTML scraping was used by prior versions of Dr Konqi - and broke quite 
 badly when Bugzilla was upgraded to 4.2.x.
 
 Ian Wadham wrote:
 @Ben Cooksley: Understood. I was thinking more along the lines of 
 connecting without starting a browser window (which would be a nuisance for 
 the user anyway), but somehow using the cookies that might have been stored 
 by the user's browser of choice, and if that fails THEN ask for username and 
 password. Our problem, on Apple OS X, is that none of Dr K works ATM if your 
 browser of choice is Safari or Firefox or even Konqueror, because the cookies 
 are stored somewhere that is not the KCookieJar. Maybe the Qt guys solved 
 this problem somewhere, e.g. when developing QDesktopServices::openUrl(). Of 
 course, Dr K must still use KXmlRpc::Client for data transfer to and fro.
 
 RJVB Bertin wrote:
 ? Maybe it's because I have Chrome as my default browser, but Konqueror 
 uses the kcookiejar over here. If I make sure kded4 is running, that is; 
 otherwise it can't.
 I do have a bit of a hard time believing that someone tweaked things so 
 that KDE would use the native cookie store but  as a function of which 
 browser you have configured as a default. (If I'd have to chose I'd say that 
 support for native plugins is a tad more useful!)
 
 Ben Cooksley wrote:
 Unfortunately Bugzilla has removed support for using cookies to submit 
 XMLRPC API queries in version 4.4, in favour of access tokens so it isn't 
 possible to do that either i'm afraid :(
 
 Ian Wadham wrote:
 It seems that bugs.kde.org has changed to using

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-08-02 Thread RJVB Bertin



 On July 27, 2014, 1:17 p.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.
 
 Aaron J. Seigo wrote:
 The login relies on cookies so the check must stAy. The check should 
 remain osx in case in future this works. However what should probably happen 
 is the Login button and text fields should be disabled pendiNg a call to see 
 if cookies are enabled. That check should made async and the message boxes 
 removed in favour oof inline messages Incliding A link to tirn cookies on 
 instead of a yes/no dialog.
 Sorry for the typos. This form barel works at all with the android web 
 browser :(
 miAnimizin
 
 Ian Wadham wrote:
 The login works OK, cookies or not. Dr K asks you to enter user name and 
 password every time, regardless of whether you are already logged in and have 
 cookies. In my case, the cookies are in Firefox in whatever location it uses 
 with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able 
 to. I have tried (briefly) going the KDE way, using Konqueror and defining it 
 (to KDE preferences) as my preferred browser and then logging in to BKO with 
 Konqueror, but on Apple OS X that is cumbersome to set up and does not work 
 predictably in Dr K, as it must if we want the average user to report bugs.
 
 After the login, it was possible to report a bug completely 
 https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie 
 check enabled one cannot report anything, because Dr K crashes in the middle 
 of the cookie check (on Apple OS X).
 
 Dr K uses remote procedure calls to do its work on BKO (class 
 KXmlRpc::Client), including logging in. See code in 
 kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K 
 could somehow connect to BKO via the user's browser of choice or cookies 
 therein, using something really portable, similar to 
 QDesktopServices::openUrl(), but I cannot see any immediate way to do that.
 
 I have another bug, not yet investigated in detail, where Dr K has lost 
 the login to BKO somehow and cannot submit the completed report, but it was 
 still able to save it in a file.
 
 It is hard to know how to test Dr K's bug-report submission thoroughly 
 without cluttering up BKO with irrelevant reports. Is there a test version of 
 the BKO database somewhere?
 
 Ben Cooksley wrote:
 The use of the Bugzilla XMLRPC api is required i'm afraid. The web 
 browser interface cannot be used - due to CSRF protections now built into it. 
 In addition, it changes from time to time breaking compatability. This form 
 of HTML scraping was used by prior versions of Dr Konqi - and broke quite 
 badly when Bugzilla was upgraded to 4.2.x.
 
 Ian Wadham wrote:
 @Ben Cooksley: Understood. I was thinking more along the lines of 
 connecting without starting a browser window (which would be a nuisance for 
 the user anyway), but somehow using the cookies that might have been stored 
 by the user's browser of choice, and if that fails THEN ask for username and 
 password. Our problem, on Apple OS X, is that none of Dr K works ATM if your 
 browser of choice is Safari or Firefox or even Konqueror, because the cookies 
 are stored somewhere that is not the KCookieJar. Maybe the Qt guys solved 
 this problem somewhere, e.g. when developing QDesktopServices::openUrl(). Of 
 course, Dr K must still use KXmlRpc::Client for data transfer to and fro.

? Maybe it's because I have Chrome as my default browser, but Konqueror uses 
the kcookiejar over here. If I make sure kded4 is running, that is; otherwise 
it can't.
I do have a bit of a hard time believing that someone tweaked things so that 
KDE would use the native cookie store but  as a function of which browser you 
have configured as a default. (If I'd have to chose I'd say that support for 
native plugins is a tad more useful!)


- RJVB


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 30, 2014, 3:04 p.m., Ian Wadham wrote:

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-08-02 Thread Ben Cooksley



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.
 
 Aaron J. Seigo wrote:
 The login relies on cookies so the check must stAy. The check should 
 remain osx in case in future this works. However what should probably happen 
 is the Login button and text fields should be disabled pendiNg a call to see 
 if cookies are enabled. That check should made async and the message boxes 
 removed in favour oof inline messages Incliding A link to tirn cookies on 
 instead of a yes/no dialog.
 Sorry for the typos. This form barel works at all with the android web 
 browser :(
 miAnimizin
 
 Ian Wadham wrote:
 The login works OK, cookies or not. Dr K asks you to enter user name and 
 password every time, regardless of whether you are already logged in and have 
 cookies. In my case, the cookies are in Firefox in whatever location it uses 
 with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able 
 to. I have tried (briefly) going the KDE way, using Konqueror and defining it 
 (to KDE preferences) as my preferred browser and then logging in to BKO with 
 Konqueror, but on Apple OS X that is cumbersome to set up and does not work 
 predictably in Dr K, as it must if we want the average user to report bugs.
 
 After the login, it was possible to report a bug completely 
 https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie 
 check enabled one cannot report anything, because Dr K crashes in the middle 
 of the cookie check (on Apple OS X).
 
 Dr K uses remote procedure calls to do its work on BKO (class 
 KXmlRpc::Client), including logging in. See code in 
 kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K 
 could somehow connect to BKO via the user's browser of choice or cookies 
 therein, using something really portable, similar to 
 QDesktopServices::openUrl(), but I cannot see any immediate way to do that.
 
 I have another bug, not yet investigated in detail, where Dr K has lost 
 the login to BKO somehow and cannot submit the completed report, but it was 
 still able to save it in a file.
 
 It is hard to know how to test Dr K's bug-report submission thoroughly 
 without cluttering up BKO with irrelevant reports. Is there a test version of 
 the BKO database somewhere?
 
 Ben Cooksley wrote:
 The use of the Bugzilla XMLRPC api is required i'm afraid. The web 
 browser interface cannot be used - due to CSRF protections now built into it. 
 In addition, it changes from time to time breaking compatability. This form 
 of HTML scraping was used by prior versions of Dr Konqi - and broke quite 
 badly when Bugzilla was upgraded to 4.2.x.
 
 Ian Wadham wrote:
 @Ben Cooksley: Understood. I was thinking more along the lines of 
 connecting without starting a browser window (which would be a nuisance for 
 the user anyway), but somehow using the cookies that might have been stored 
 by the user's browser of choice, and if that fails THEN ask for username and 
 password. Our problem, on Apple OS X, is that none of Dr K works ATM if your 
 browser of choice is Safari or Firefox or even Konqueror, because the cookies 
 are stored somewhere that is not the KCookieJar. Maybe the Qt guys solved 
 this problem somewhere, e.g. when developing QDesktopServices::openUrl(). Of 
 course, Dr K must still use KXmlRpc::Client for data transfer to and fro.
 
 RJVB Bertin wrote:
 ? Maybe it's because I have Chrome as my default browser, but Konqueror 
 uses the kcookiejar over here. If I make sure kded4 is running, that is; 
 otherwise it can't.
 I do have a bit of a hard time believing that someone tweaked things so 
 that KDE would use the native cookie store but  as a function of which 
 browser you have configured as a default. (If I'd have to chose I'd say that 
 support for native plugins is a tad more useful!)

Unfortunately Bugzilla has removed support for using cookies to submit XMLRPC 
API queries in version 4.4, in favour of access tokens so it isn't possible to 
do that either i'm afraid :(


- Ben


---
This is an automatically generated

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-08-01 Thread Ben Cooksley



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.
 
 Aaron J. Seigo wrote:
 The login relies on cookies so the check must stAy. The check should 
 remain osx in case in future this works. However what should probably happen 
 is the Login button and text fields should be disabled pendiNg a call to see 
 if cookies are enabled. That check should made async and the message boxes 
 removed in favour oof inline messages Incliding A link to tirn cookies on 
 instead of a yes/no dialog.
 Sorry for the typos. This form barel works at all with the android web 
 browser :(
 miAnimizin
 
 Ian Wadham wrote:
 The login works OK, cookies or not. Dr K asks you to enter user name and 
 password every time, regardless of whether you are already logged in and have 
 cookies. In my case, the cookies are in Firefox in whatever location it uses 
 with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able 
 to. I have tried (briefly) going the KDE way, using Konqueror and defining it 
 (to KDE preferences) as my preferred browser and then logging in to BKO with 
 Konqueror, but on Apple OS X that is cumbersome to set up and does not work 
 predictably in Dr K, as it must if we want the average user to report bugs.
 
 After the login, it was possible to report a bug completely 
 https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie 
 check enabled one cannot report anything, because Dr K crashes in the middle 
 of the cookie check (on Apple OS X).
 
 Dr K uses remote procedure calls to do its work on BKO (class 
 KXmlRpc::Client), including logging in. See code in 
 kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K 
 could somehow connect to BKO via the user's browser of choice or cookies 
 therein, using something really portable, similar to 
 QDesktopServices::openUrl(), but I cannot see any immediate way to do that.
 
 I have another bug, not yet investigated in detail, where Dr K has lost 
 the login to BKO somehow and cannot submit the completed report, but it was 
 still able to save it in a file.
 
 It is hard to know how to test Dr K's bug-report submission thoroughly 
 without cluttering up BKO with irrelevant reports. Is there a test version of 
 the BKO database somewhere?

The use of the Bugzilla XMLRPC api is required i'm afraid. The web browser 
interface cannot be used - due to CSRF protections now built into it. In 
addition, it changes from time to time breaking compatability. This form of 
HTML scraping was used by prior versions of Dr Konqi - and broke quite badly 
when Bugzilla was upgraded to 4.2.x.


- Ben


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 30, 2014, 1:04 p.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated July 30, 2014, 1:04 p.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-08-01 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.
 
 Aaron J. Seigo wrote:
 The login relies on cookies so the check must stAy. The check should 
 remain osx in case in future this works. However what should probably happen 
 is the Login button and text fields should be disabled pendiNg a call to see 
 if cookies are enabled. That check should made async and the message boxes 
 removed in favour oof inline messages Incliding A link to tirn cookies on 
 instead of a yes/no dialog.
 Sorry for the typos. This form barel works at all with the android web 
 browser :(
 miAnimizin
 
 Ian Wadham wrote:
 The login works OK, cookies or not. Dr K asks you to enter user name and 
 password every time, regardless of whether you are already logged in and have 
 cookies. In my case, the cookies are in Firefox in whatever location it uses 
 with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able 
 to. I have tried (briefly) going the KDE way, using Konqueror and defining it 
 (to KDE preferences) as my preferred browser and then logging in to BKO with 
 Konqueror, but on Apple OS X that is cumbersome to set up and does not work 
 predictably in Dr K, as it must if we want the average user to report bugs.
 
 After the login, it was possible to report a bug completely 
 https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie 
 check enabled one cannot report anything, because Dr K crashes in the middle 
 of the cookie check (on Apple OS X).
 
 Dr K uses remote procedure calls to do its work on BKO (class 
 KXmlRpc::Client), including logging in. See code in 
 kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K 
 could somehow connect to BKO via the user's browser of choice or cookies 
 therein, using something really portable, similar to 
 QDesktopServices::openUrl(), but I cannot see any immediate way to do that.
 
 I have another bug, not yet investigated in detail, where Dr K has lost 
 the login to BKO somehow and cannot submit the completed report, but it was 
 still able to save it in a file.
 
 It is hard to know how to test Dr K's bug-report submission thoroughly 
 without cluttering up BKO with irrelevant reports. Is there a test version of 
 the BKO database somewhere?
 
 Ben Cooksley wrote:
 The use of the Bugzilla XMLRPC api is required i'm afraid. The web 
 browser interface cannot be used - due to CSRF protections now built into it. 
 In addition, it changes from time to time breaking compatability. This form 
 of HTML scraping was used by prior versions of Dr Konqi - and broke quite 
 badly when Bugzilla was upgraded to 4.2.x.

@Ben Cooksley: Understood. I was thinking more along the lines of connecting 
without starting a browser window (which would be a nuisance for the user 
anyway), but somehow using the cookies that might have been stored by the 
user's browser of choice, and if that fails THEN ask for username and password. 
Our problem, on Apple OS X, is that none of Dr K works ATM if your browser of 
choice is Safari or Firefox or even Konqueror, because the cookies are stored 
somewhere that is not the KCookieJar. Maybe the Qt guys solved this problem 
somewhere, e.g. when developing QDesktopServices::openUrl(). Of course, Dr K 
must still use KXmlRpc::Client for data transfer to and fro.


- Ian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 30, 2014, 1:04 p.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated July 30, 2014, 1:04 p.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 When a KDE app crashes in Apple OS X, it just disappears from the screen. At 
 the most, the user

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-31 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It returns

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-31 Thread Aaron J. Seigo



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It returns

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-31 Thread RJVB Bertin



 On July 27, 2014, 1:17 p.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It returns

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-31 Thread Thomas Lübking



 On Juli 27, 2014, 11:17 vorm., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-31 Thread RJVB Bertin



 On July 27, 2014, 1:17 p.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It returns

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-31 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.
 
 Aaron J. Seigo wrote:
 The login relies on cookies so the check must stAy. The check should 
 remain osx in case in future this works. However what should probably happen 
 is the Login button and text fields should be disabled pendiNg a call to see 
 if cookies are enabled. That check should made async and the message boxes 
 removed in favour oof inline messages Incliding A link to tirn cookies on 
 instead of a yes/no dialog.
 Sorry for the typos. This form barel works at all with the android web 
 browser :(
 miAnimizin

The login works OK, cookies or not. Dr K asks you to enter user name and 
password every time, regardless of whether you are already logged in and have 
cookies. In my case, the cookies are in Firefox in whatever location it uses 
with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able 
to. I have tried (briefly) going the KDE way, using Konqueror and defining it 
(to KDE preferences) as my preferred browser and then logging in to BKO with 
Konqueror, but on Apple OS X that is cumbersome to set up and does not work 
predictably in Dr K, as it must if we want the average user to report bugs.

After the login, it was possible to report a bug completely 
https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie 
check enabled one cannot report anything, because Dr K crashes in the middle of 
the cookie check (on Apple OS X).

Dr K uses remote procedure calls to do its work on BKO (class KXmlRpc::Client), 
including logging in. See code in kde-runtime/drkonqi/bugzillalib.cpp, lines 
68-210. It would be nice if Dr K could somehow connect to BKO via the user's 
browser of choice or cookies therein, using something really portable, similar 
to QDesktopServices::openUrl(), but I cannot see any immediate way to do that.

I have another bug, not yet investigated in detail, where Dr K has lost the 
login to BKO somehow and cannot submit the completed report, but it was still 
able to save it in a file.

It is hard to know how to test Dr K's bug-report submission thoroughly without 
cluttering up BKO with irrelevant reports. Is there a test version of the BKO 
database somewhere?


- Ian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 30, 2014, 1:04 p.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated July 30, 2014, 1:04 p.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-30 Thread RJVB Bertin



 On July 27, 2014, 1:17 p.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.

If it walks and talks like a crash ... we should not end up in the discussion 
deadlock I once had with my boss who claimed embedded code cannot crash 
(because there's no OS or whatelse to replace the application code).

Anyway, I like Ian's suggestion to just return to the caller instead of 
exitting (and I concur with his lazy programming analysis).

So if I understood correctly, DrKonqi does some reformatting of the backtrace 
before including it for upload with the bug report. What I haven't understood 
is how important this reformatting is. Could it be a thought to cancel the 
reformating procedure and return with the raw text, instead of with a partly 
formated text, when the assert condition triggers?


About processing backtraces: recent OS X versions use lldb instead of gdb. How 
have you tackled that, Ian - added a dependency on port:gdb ?


- RJVB


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


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

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-30 Thread Aaron J. Seigo



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.
 
 Thomas Lübking wrote:
 Well, the claim is that aborting for no cookie support is wrong in the 
 first place.
 If so, drop the code.
 If not (or unsure) please don't break it with an unrelated patch.

The login relies on cookies so the check must stAy. The check should remain osx 
in case in future this works. However what should probably happen is the Login 
button and text fields should be disabled pendiNg a call to see if cookies are 
enabled. That check should made async and the message boxes removed in favour 
oof inline messages Incliding A link to tirn cookies on instead of a yes/no 
dialog.
Sorry for the typos. This form barel works at all with the android web browser 
:(
miAnimizin


 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-30 Thread RJVB Bertin



 On July 27, 2014, 1:17 p.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It returns

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-30 Thread Thomas Lübking



 On Juli 27, 2014, 11:17 vorm., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-30 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It returns

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-30 Thread Thomas Lübking



 On Juli 27, 2014, 11:17 vorm., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.
 
 Ian Wadham wrote:
 Please spare me the motoring analogies. To me, the ASSERT at this point, 
 is like bringing the car to a screeching halt or running it into the nearest 
 fence, simply because the glovebox light will not come on. I am a real-time 
 and O/S programmer from way back and have designed and written a few crash 
 procedures for different systems. They need to be rugged and simple (unlike 
 Dr Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
 programming, graceful failure or graceful degradation. If an ASSERT and abort 
 technique has to be used in RT programming, to prevent potential database 
 corruption, it needs to be backed by an appropriate recovery and restart 
 procedure.
 
 Actually I think lines.end() is a legitimate return from 
 lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
 http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
 lineNr can actually get ahead of the number of lines in the map by by too 
 much, if there are several multi-line entries in QString text. Using an 
 ASSERT looks like lazy programming to me (Thinks: I cannot see what to do in 
 this case, so I'll put in an ASSERT and see if it actually happens in 
 practice. ???). My solution is to re-use the last entry from the QMap. 
 Another might be to use return; instead of the ASSERT, leaving the last bit 
 of the highlighting incomplete, but not losing the valuable backtrace data.
 
 A better (more rugged) approach might be:
 
 get a line from text
 if it is from the left-hand end of a backtrace entry (i.e. not a 
 continuation line)
 get the next backtrace entry
 if past last entry
 return
 re-format the line from text
 
 I would have used something like that in my patch, but I do not know 
 enough about the format of backtrace data to get the first if condition 
 right. How would I?
 
 Re \n characters, they occur as expected in the content of QString 
 text on Apple OS X.
 
 RJVB Bertin wrote:
 If it walks and talks like a crash ... we should not end up in the 
 discussion deadlock I once had with my boss who claimed embedded code cannot 
 crash (because there's no OS or whatelse to replace the application code).
 
 Anyway, I like Ian's suggestion to just return to the caller instead of 
 exitting (and I concur with his lazy programming analysis).
 
 So if I understood correctly, DrKonqi does some reformatting of the 
 backtrace before including it for upload with the bug report. What I haven't 
 understood is how important this reformatting is. Could it be a thought to 
 cancel the reformating procedure and return with the raw text, instead of 
 with a partly formated text, when the assert condition triggers?
 
 
 About processing backtraces: recent OS X versions use lldb instead of 
 gdb. How have you tackled that, Ian - added a dependency on port:gdb ?
 
 Aaron J. Seigo wrote:
 This is not lazy programming but programming by contract. That it reaches 
 the lasT of lines is a bug... it should nEver happen algorithmic Ally. The 
 bug appears to be lowerbound sage. It

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-29 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/main.cpp, line 111
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293511#file293511line111
 
  This can go unconditionally.
  
  Show really only shows the window.
  Becoming active and then raise for that is WM detail - and WMs have to 
  deal with inadequate raise requests anyway ;-)

I do not understand your comments at all.

I just know that the raise() is essential in this context, otherwise the 
end-user never sees Dr Konqi's window and never investigates or reports the 
crash.

On Apple OS X, an app which is started properly, by clicking an icon or 
running an Apple OS X open command, will raise the app's window, but Dr Konqi 
is not being started this way.


- Ian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 27, 2014, 9:16 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated July 27, 2014, 9:16 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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 
 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
 Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
 repositories. I am sure there are many more Apple OS X portability problems 
 in Dr Konqi and other KDE software.
 
 Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, 
 often fails to complete the backtrace report and then fails to connect to 
 bugs.kde.org.
 
 With my patches, Dr Konqi on Apple OS X can generate a full crash report, 
 including the backtrace and the results of the dialog with the user. 
 Sometimes, however, it fails to submit the completed report to bugs.kde.org. 
 This problem is still under

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-29 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 286
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line286
 
  #ifndef

No, #ifdef. The lines following 286 apply to Apple OS X and nothing else. ATM 
they are only explanatory. But there is a place to add code if anybody can 
think of something appropriate (e.g. to check for cookies on the user's browser 
of choice in a portable way, maybe using Qt).


 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)

The comments on lines 295-298 explain why I have commented out the return 
statement. I am hoping a KDE core developer can suggest a better way of 
handling the situation than aborting Dr Konqi.


- Ian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 27, 2014, 9:16 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated July 27, 2014, 9:16 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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 
 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
 Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
 repositories. I am sure there are many more Apple OS X portability problems 
 in Dr Konqi and other KDE software.
 
 Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, 
 often

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-29 Thread RJVB Bertin



 On July 27, 2014, 1:17 p.m., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 286
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line286
 
  #ifndef
 
 Ian Wadham wrote:
 No, #ifdef. The lines following 286 apply to Apple OS X and nothing else. 
 ATM they are only explanatory. But there is a place to add code if anybody 
 can think of something appropriate (e.g. to check for cookies on the user's 
 browser of choice in a portable way, maybe using Qt).

Probably not relevant here at all, but mentioning a place to add appropriate 
code for this kind of thing reminds me of the fact that browser plugins are 
organised in a quite different way on OS X, and it would be great if konqueror 
could pick them up. Just sayin', for the record :)


- RJVB


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 27, 2014, 11:16 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated July 27, 2014, 11:16 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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 
 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
 Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
 repositories. I am sure there are many more Apple OS X portability problems 
 in Dr Konqi and other KDE software.
 
 Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, 
 often fails to complete the backtrace report and then fails to connect to 
 bugs.kde.org.
 
 With my patches, Dr Konqi on Apple OS X can generate a full crash report, 
 including the backtrace and the results of the dialog with the user. 
 Sometimes, however, it fails to submit the completed report to bugs.kde.org.

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-29 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?

I did at one time have a few qDebug() statements to try and find what was wrong 
with the algorithm. AFAICT it is trying to match one or more lines in (const 
QString text) with single (possibly long) lines of backtrace in QMapint, 
BacktraceLine. I think it failed if one backtrace line was formatted into 
three text lines or maybe if the last backtrace line was formatted into two 
text lines. AFAICT (there is a real dearth of explanatory comments) the code is 
merely introducing pretty colours, etc. into the formatted text. As such, it 
should not abort Dr Konqi and lose the crash report.


- Ian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 27, 2014, 9:16 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated July 27, 2014, 9:16 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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 
 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
 Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
 repositories. I am sure there are many more Apple OS X portability problems 
 in Dr Konqi and other KDE software.
 
 Without my patches, Dr Konqi, on Apple OS X, remains

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-29 Thread Thomas Lübking



 On Juli 27, 2014, 11:17 vorm., Thomas Lübking wrote:
  drkonqi/main.cpp, line 111
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293511#file293511line111
 
  This can go unconditionally.
  
  Show really only shows the window.
  Becoming active and then raise for that is WM detail - and WMs have to 
  deal with inadequate raise requests anyway ;-)
 
 Ian Wadham wrote:
 I do not understand your comments at all.
 
 I just know that the raise() is essential in this context, otherwise the 
 end-user never sees Dr Konqi's window and never investigates or reports the 
 crash.
 
 On Apple OS X, an app which is started properly, by clicking an icon or 
 running an Apple OS X open command, will raise the app's window, but Dr 
 Konqi is not being started this way.

You can omit the system test.
It's ok to call raise() here on any system.


 On Juli 27, 2014, 11:17 vorm., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 286
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line286
 
  #ifndef
 
 Ian Wadham wrote:
 No, #ifdef. The lines following 286 apply to Apple OS X and nothing else. 
 ATM they are only explanatory. But there is a place to add code if anybody 
 can think of something appropriate (e.g. to check for cookies on the user's 
 browser of choice in a portable way, maybe using Qt).
 
 RJVB Bertin wrote:
 Probably not relevant here at all, but mentioning a place to add 
 appropriate code for this kind of thing reminds me of the fact that browser 
 plugins are organised in a quite different way on OS X, and it would be great 
 if konqueror could pick them up. Just sayin', for the record :)

I meant to use an #ifndef (and reverse the logic of course) because some #else 
branch is actually not required - unless of course you indeed want to add some 
apple specific code.


 On Juli 27, 2014, 11:17 vorm., Thomas Lübking wrote:
  drkonqi/reportassistantpages_bugzilla.cpp, line 300
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300
 
  this is commented.
  
  if the test is pointless altogether (i do not know. no idea. no record 
  on drkonqui) just remove it with the comment in the commit message, but 
  ifdeffing a void statement makes us look silly ;-)
 
 Ian Wadham wrote:
 The comments on lines 295-298 explain why I have commented out the return 
 statement. I am hoping a KDE core developer can suggest a better way of 
 handling the situation than aborting Dr Konqi.

Well, the claim is that aborting for no cookie support is wrong in the first 
place.
If so, drop the code.
If not (or unsure) please don't break it with an unrelated patch.


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On Juli 27, 2014, 9:16 vorm., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated Juli 27, 2014, 9:16 vorm.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-29 Thread Thomas Lübking



 On Juli 27, 2014, 11:17 vorm., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.

Of course it should not crash.

The point is that the assert explicitly tells you that there's something wrong 
with the code.
Skippping it won't fix the issu - that's like puting duct tape over a warning 
sign on your cars dashboard to fix no cooling water.


Since the lines map seems only used to map lines to textblocks, i assume the 
issue is that the lines are eg. not \n terminated in gdb output on OSX (no 
idea, though) and the only item in the map is that for the key 0

In this case that'd be the issue to fix.


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On Juli 27, 2014, 9:16 vorm., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated Juli 27, 2014, 9:16 vorm.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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,

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-29 Thread Ian Wadham



 On July 27, 2014, 11:17 a.m., Thomas Lübking wrote:
  drkonqi/gdbhighlighter.cpp, line 74
  https://git.reviewboard.kde.org/r/119498/diff/1/?file=293510#file293510line74
 
  an abort is not a crash ;-)
  
  If you hit this assert, the looked up (lineNr - 1) is somehow out of 
  bounds, ie. there's no line with a key = (lineNr -1) in the map.
  
  This should likely never happen on any system.
  Can you check what the lineNr actually is as compared to
  
 qDebug()  lineNr  lines.keys();
 
  ?
 
 Ian Wadham wrote:
 I did at one time have a few qDebug() statements to try and find what was 
 wrong with the algorithm. AFAICT it is trying to match one or more lines in 
 (const QString text) with single (possibly long) lines of backtrace in 
 QMapint, BacktraceLine. I think it failed if one backtrace line was 
 formatted into three text lines or maybe if the last backtrace line was 
 formatted into two text lines. AFAICT (there is a real dearth of explanatory 
 comments) the code is merely introducing pretty colours, etc. into the 
 formatted text. As such, it should not abort Dr Konqi and lose the crash 
 report.
 
 Thomas Lübking wrote:
 Of course it should not crash.
 
 The point is that the assert explicitly tells you that there's something 
 wrong with the code.
 Skippping it won't fix the issu - that's like puting duct tape over a 
 warning sign on your cars dashboard to fix no cooling water.
 
 
 Since the lines map seems only used to map lines to textblocks, i assume 
 the issue is that the lines are eg. not \n terminated in gdb output on OSX 
 (no idea, though) and the only item in the map is that for the key 0
 
 In this case that'd be the issue to fix.

Please spare me the motoring analogies. To me, the ASSERT at this point, is 
like bringing the car to a screeching halt or running it into the nearest 
fence, simply because the glovebox light will not come on. I am a real-time and 
O/S programmer from way back and have designed and written a few crash 
procedures for different systems. They need to be rugged and simple (unlike Dr 
Konqi IMHO) and to succeed no matter what. This used to be called failsafe 
programming, graceful failure or graceful degradation. If an ASSERT and abort 
technique has to be used in RT programming, to prevent potential database 
corruption, it needs to be backed by an appropriate recovery and restart 
procedure.

Actually I think lines.end() is a legitimate return from 
lines.lowerBound(lineNr - 1) in Dr K's algorithm (see 
http://qt-project.org/doc/qt-5/qmap.html#lowerBound coding examples). The 
lineNr can actually get ahead of the number of lines in the map by by too much, 
if there are several multi-line entries in QString text. Using an ASSERT looks 
like lazy programming to me (Thinks: I cannot see what to do in this case, so 
I'll put in an ASSERT and see if it actually happens in practice. ???). My 
solution is to re-use the last entry from the QMap. Another might be to use 
return; instead of the ASSERT, leaving the last bit of the highlighting 
incomplete, but not losing the valuable backtrace data.

A better (more rugged) approach might be:

get a line from text
if it is from the left-hand end of a backtrace entry (i.e. not a 
continuation line)
get the next backtrace entry
if past last entry
return
re-format the line from text

I would have used something like that in my patch, but I do not know enough 
about the format of backtrace data to get the first if condition right. How 
would I?

Re \n characters, they occur as expected in the content of QString text on 
Apple OS X.


- Ian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---


On July 27, 2014, 9:16 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated July 27, 2014, 9:16 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-27 Thread Ian Wadham


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/
---

(Updated July 27, 2014, 9:16 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 (2) (fix drkonqi)


Repository: kde-runtime


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. Three patches for Dr Konqi are 
submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 
1 of this review, against kdelibs. I am still investigating the other two 
problems in Dr Konqi - and there could be more than two...

In this review we have three portability problems:

1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window 
of the app that has just crashed, so is effectively useless. This appears to be 
because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an 
app is started with the Apple OS X open command, it always appears on top. 
The patch just raises the dialog box.

2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
the last line. This appears to be an error in the algorithm used (i.e. also a 
bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
problem for now.

3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, 
stops reporting the crash. On Apple OS X, cookies would be kept in another 
browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) 
and cookie jar. IMHO, Dr K should report the crash no matter what, as long as 
it can connect to bugs.kde.org and log in.


Diffs
-

  drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
  drkonqi/gdbhighlighter.cpp 7cd0aa9 
  drkonqi/main.cpp 75e060e 

Diff: https://git.reviewboard.kde.org/r/119498/diff/


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 will 
also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
repositories. I am sure there are many more Apple OS X portability problems in 
Dr Konqi and other KDE software.

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, 
often fails to complete the backtrace report and then fails to connect to 
bugs.kde.org.

With my patches, Dr Konqi on Apple OS X can generate a full crash report, 
including the backtrace and the results of the dialog with the user. Sometimes, 
however, it fails to submit the completed report to bugs.kde.org. This problem 
is still under investigation.

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 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-07-27 Thread Thomas Lübking


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review63254
---



drkonqi/gdbhighlighter.cpp
https://git.reviewboard.kde.org/r/119498/#comment44043

an abort is not a crash ;-)

If you hit this assert, the looked up (lineNr - 1) is somehow out of 
bounds, ie. there's no line with a key = (lineNr -1) in the map.

This should likely never happen on any system.
Can you check what the lineNr actually is as compared to

   qDebug()  lineNr  lines.keys();
   
?



drkonqi/main.cpp
https://git.reviewboard.kde.org/r/119498/#comment44044

This can go unconditionally.

Show really only shows the window.
Becoming active and then raise for that is WM detail - and WMs have to deal 
with inadequate raise requests anyway ;-)



drkonqi/reportassistantpages_bugzilla.cpp
https://git.reviewboard.kde.org/r/119498/#comment44045

#ifndef



drkonqi/reportassistantpages_bugzilla.cpp
https://git.reviewboard.kde.org/r/119498/#comment44046

this is commented.

if the test is pointless altogether (i do not know. no idea. no record on 
drkonqui) just remove it with the comment in the commit message, but ifdeffing 
a void statement makes us look silly ;-)


- Thomas Lübking


On Juli 27, 2014, 9:16 vorm., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119498/
 ---
 
 (Updated Juli 27, 2014, 9:16 vorm.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
 Michael Pyne.
 
 
 Repository: kde-runtime
 
 
 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. Three patches for Dr Konqi are 
 submitted in this review. Patches for KCrash and kdeinit4 are submitted in 
 part 1 of this review, against kdelibs. I am still investigating the other 
 two problems in Dr Konqi - and there could be more than two...
 
 In this review we have three portability problems:
 
 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main 
 window of the app that has just crashed, so is effectively useless. This 
 appears to be because Dr Konqi is started by a Linux/Unix method (fork() + 
 exec()?). If an app is started with the Apple OS X open command, it always 
 appears on top. The patch just raises the dialog box.
 
 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on 
 the last line. This appears to be an error in the algorithm used (i.e. also a 
 bug in Linux KDE), but the patch is treating it as an Apple OS X portability 
 problem for now.
 
 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if 
 not, stops reporting the crash. On Apple OS X, cookies would be kept in 
 another browser (e.g. Safari or Firefox) and not in KDE's default browser 
 (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter 
 what, as long as it can connect to bugs.kde.org and log in.
 
 
 Diffs
 -
 
   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
   drkonqi/gdbhighlighter.cpp 7cd0aa9 
   drkonqi/main.cpp 75e060e 
 
 Diff: https://git.reviewboard.kde.org/r/119498/diff/
 
 
 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 
 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test 
 Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks 
 repositories. I am sure there are many more Apple OS X portability problems 
 in Dr Konqi and other KDE software.
 
 Without my patches, Dr Konqi, on

48 matches

Mail list logo