Using recent GIT sources, does DrKonqi work correctly to create backtraces?
When I run crashtest in 3.5.10, DrKonqi creates a backtrace. In TDE all I get is the following message:
"This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash."
This worked some time in the past (I am the one who patched tdebase so crashtest would build).
My build scripts all use --enable-debug=full for automake and -ggdb for cmake. The build logs show that the packages are compiling with those flags and the increased package sizes are further evidence.
Yet I can't create a backtrace through DrKonqi. The crashtest binary should be sufficient to test DrKonqi.
Would somebody running a recent GIT please confirm whether they can create a backtrace with DrKonqi?
Thanks.
Darrell
Using recent GIT sources, does DrKonqi work correctly to create backtraces?
When I run crashtest in 3.5.10, DrKonqi creates a backtrace. In TDE all I get is the following message:
"This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash."
This worked some time in the past (I am the one who patched tdebase so crashtest would build).
My build scripts all use --enable-debug=full for automake and -ggdb for cmake. The build logs show that the packages are compiling with those flags and the increased package sizes are further evidence.
Yet I can't create a backtrace through DrKonqi. The crashtest binary should be sufficient to test DrKonqi.
Would somebody running a recent GIT please confirm whether they can create a backtrace with DrKonqi?
Thanks.
Darrell
No luck here, but then again gdb isn't working for me either.
I would verify that we aren't getting bit by the ptrace security patch that was applied to Ubuntu some time ago, and may be filtering into other distributions by now. See if you can attach to a process with gdb as a normal user--if you can, and DrKonqui still doesn't work, then we have a problem.
Tim
Would somebody running a recent GIT please confirm whether they can create a backtrace with DrKonqi?
No luck here, but then again gdb isn't working for me either.
I would verify that we aren't getting bit by the ptrace security patch that was applied to Ubuntu some time ago, and may be filtering into other distributions by now.
Which patch is that? I'm testing this on Slackware 13.1, which uses glibc 2.11.1, kernel 2.6.33.x. I don't think any such patch is part of 13.1.
See if you can attach to a process with gdb as a normal user--if you can, and DrKonqui still doesn't work, then we have a problem.
Perhaps provide me the exact steps you want to me follow to test gdb. That is, last week when I could not start konqueror, just after the tdelibs ABI patch, I created a backtrace like this:
gdb -- arg konqueror run bt
If that is sufficient, then drkonqi is broken?
Darrell
Would somebody running a recent GIT please confirm whether they can
create
a backtrace with DrKonqi?
No luck here, but then again gdb isn't working for me either.
I would verify that we aren't getting bit by the ptrace security patch that was applied to Ubuntu some time ago, and may be filtering into other distributions by now.
Which patch is that? I'm testing this on Slackware 13.1, which uses glibc 2.11.1, kernel 2.6.33.x. I don't think any such patch is part of 13.1.
It very well may not be--here's the Ubuntu patch and security discussion: https://wiki.ubuntu.com/Security/Features#ptrace
See if you can attach to a process with gdb as a normal user--if you can, and DrKonqui still doesn't work, then we have a problem.
Perhaps provide me the exact steps you want to me follow to test gdb. That is, last week when I could not start konqueror, just after the tdelibs ABI patch, I created a backtrace like this:
gdb -- arg konqueror run bt
If that is sufficient, then drkonqi is broken?
The steps I was thinking were these: 1.) Start a TDE process, noting its PID 2.) Run gdb 3.) attach <pid>
If you see a bunch of debugging symbols being loaded then gdb is working fine, and DrKonqui is broken. If gdb spits out an error, then something else has gone wrong.
Tim
The steps I was thinking were these: 1.) Start a TDE process, noting its PID 2.) Run gdb 3.) attach <pid>
If you see a bunch of debugging symbols being loaded then gdb is working fine, and DrKonqui is broken. If gdb spits out an error, then something else has gone wrong.
I tested with kwrite. I see symbols being loaded for all Trinity packages.
Anything else I can test before opening a bug report?
Darrell
The steps I was thinking were these: 1.) Start a TDE process, noting its PID 2.) Run gdb 3.) attach <pid>
If you see a bunch of debugging symbols being loaded then gdb is working fine, and DrKonqui is broken. If gdb spits out an error, then something else has gone wrong.
I tested with kwrite. I see symbols being loaded for all Trinity packages.
Anything else I can test before opening a bug report?
Darrell
No, it sounds like there is a definite bug here. Please post detailed steps for reproduction in a BLOCKER bug report.
Tim
-
Darrell Anderson -
Timothy Pearson