Bug 1005

Modifying the report to a regression for easier identification.

Issue trace to this commit:
http://git.trinitydesktop.org/cgit/tdelibs/commit/tdecore/kcrash.cpp?id=77f4891c222583c8deffc34732ccf325bac9e11b

Not sure what "build warning" was fixed with that commit, as no warnings were shown when I compiled the fixed file.  I suppose a gcc glitch may have incorrectly shown a warning at some point.

Fixed in GIT hash 0dcda4b.

Thanks for reporting!

Am I doing something wrong? Running crashtest from konsole here results in no backtrace. Dr. Konqi opens but no backtrace. Does crashtest work on your system?

Have you rebuilt and reinstalled tdelibs?  crashtest works here with the patch from GIT.

Yes, rebuilt. Just to be sure, I rebuilt tdelibs and tdebase again in the last hour and verified tdelibs in my local GIT sources had the patch.

Running crashtest invokes Dr. Konqi but there is no backtrace. Just the same "This backtrace appears to be of no use...."

Package sizes are huge, therefore I presume the debugging symbols are being built and no stripped correctly. My build logs all show debugging enabled as well.

When I run crashtest in 3.5.10 I see the following:

[Thread debugging using libthread_db enabled]
[KCrash handler]
#5  0xb714d160 in KCmdLineArgs::arg(int) const () from /usr/lib/libkdecore.so.4
#6  0x08048f1e in ?? ()
#7  0x080490f9 in ?? ()
#8  0xb60b1b86 in __libc_start_main () from /lib/libc.so.6
#9  0x08048e11 in ?? ()

I befuddled by this. I'm building with debug support. Yet Dr. Konqi does not produce a backtrace when I run crashtest (works fine in 3.5.10). How do I methodically troubleshoot this?

One thing I can think of is that ptrace on my Ubuntu systems requires sudo access, so I am always prompted for sudo access before the backtrace is generated.  I wonder if the code that handles non-sudo backtraces is broken somehow.

Ah. Makes sense. The stock Slackware does not install ptrace. Let me run an experimental build by reversing the patch from GIT hash ad1a7141.

Bingo! Good thinking!

Reversing the patch from GIT hash ad1a7141 now produces a backtrace with crashtest and Dr. Konqi.

When TDE fails to generate a backtrace, do you see the tdesu prompt, or does it just fail silently?

There is no tdesu prompt. Note: On Slackware there should not be a tdesu prompt, therefore what I see in that respect is good.

(In reply to comment #11)
> There is no tdesu prompt. Note: On Slackware there should not be a tdesu
> prompt, therefore what I see in that respect is good.

So tdesu is not installed on your system?

Yes, tdesu is installed.

What I meant in my previous reply is that on Slackware, forcing users to use tdesu to produce a backtrace will be ill received. Slackware users expect to just produce a backtrace, just like the 3.5.10 days, and just like I can now do again by reversing the patch from GIT hash ad1a7141. I suspect users of other non sudo distros expect likewise. That was the point I was trying to make. :-)

(In reply to comment #13)
> Yes, tdesu is installed.
> 
> What I meant in my previous reply is that on Slackware, forcing users to use
> tdesu to produce a backtrace will be ill received. Slackware users expect to
> just produce a backtrace, just like the 3.5.10 days, and just like I can now do
> again by reversing the patch from GIT hash ad1a7141. I suspect users of other
> non sudo distros expect likewise. That was the point I was trying to make. :-)

I understand this. :-)  I am trying to figure out why/where drkonqui is failing, hence my questions.

Backtrace generation will likely require tdesu at some point in the future as more distributions and organizations adopt a stricter kernel/process security policy.  Ubuntu has already done this; the KDE 3.5.10 DrKonqui fails to generate backtraces on Ubuntu as a result.

I'll see what can be done to detect less-secure installations/distributions and bypass tdesu for them, but I don't know how to do this at the moment.

Okay.

I looked, but the code is too complicated for me to figure out. I wonder if this removed snippet is the culprit:

-  TQString str = m_krashconf->debuggerBatch();
-  m_krashconf->expandString(str, true, m_temp->name());

I could try restoring only those lines. I just hate these rebuilds. So much time to test simple changes....

Just thinking out loud: would a build option help? Such as -DWITH_DRKONQUI_SUDO? When set to ON the patch is applied and when set to OFF the old 3.5.10 code is used. Then add some ifdef statements....

(In reply to comment #15)
> Okay.
> 
> I looked, but the code is too complicated for me to figure out. I wonder if
> this removed snippet is the culprit:
> 
> -  TQString str = m_krashconf->debuggerBatch();
> -  m_krashconf->expandString(str, true, m_temp->name());
> 
> I could try restoring only those lines. I just hate these rebuilds. So much
> time to test simple changes....

Those lines are still present, just in a different location; see http://git.trinitydesktop.org/cgit/tdebase/tree/drkonqi/backtrace.cpp

I'm a bit befuddled by this; drkonqui should immediately attempt to execute the gdb batch command via tdesu.  Is there any possibility that tdesu execution is being blocked (tdesu is not on your $PATH, etc.)?

Hmm, it suddenly started failing here.  I'll see if I can track down the problem.

Apparently the tdesu arguments were not 100% compatible with the tdesudo arguments, so when I was testing with tdesudo it worked, whereas it failed with tdesu.

This has been fixed in GIT hash 59ee4f6.

I rebuilt and tested without the reversed patch. I can obtain a backtrace --- but only after being prompted to enter root's password. That won't go over well with users of non sudo distros. There has to be a way to not go through tdesu.... regardless of what Mr. Shuttleworth envisions for world peace and domination. :-)

(In reply to comment #20)
> I rebuilt and tested without the reversed patch. I can obtain a backtrace ---
> but only after being prompted to enter root's password. That won't go over well
> with users of non sudo distros. There has to be a way to not go through
> tdesu.... regardless of what Mr. Shuttleworth envisions for world peace and
> domination. :-)

OK, at least we know that works properly. :-)

I have committed a patch to GIT in hash 3046157 which looks at the yama ptrace setting in /proc/sys to determine if root access will be needed to generate the backtrace.  Backtrace generation will therefore fail if non-root ptrace has been disabled via some other method, but systems configured/patched that way should be rare enough in the wild as to be of little concern.

Latest patch is working here with no tdesu requirement.

All is well. Thank you and great work!