Oddball request, but I need a way to crash Trinity. :)
I created bug report 769 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=769). Basically, on one particular computer I am able to get Ark to crash consistently.
Yesterday I started tinkering with building my packages with separate debug packages rather than building the debugging symbols into one package. I figure outside of the devs and packagers most end-users are not interested in that support. :(
Today on that same computer I installed new packages for kdelibs, kdebase, and kdeutils: six packages instead of three.
Now I can't get Ark to crash.
1. I don't pretend to understand the nuances of debugging symbols, but by splitting the debug symbols into a separate package, could I have resolved the bug? Does that make sense?
2. I need a way to crash something in Trinity so I can test my split packages. I have browsed through the bugzilla and could not find anything that was repeatable here. Would someone please suggest a way to test the Dr. Konqi crash handler so I can generate a backtrace? My request is not related to point 1 above --- I just want to test whether my new package scheme is working and I need a way to verify I can generate a backtrace in Trinity. Perhaps there is a built-in easter egg or something that can do just that?
Darrell
Oddball request, but I need a way to crash Trinity. :)
Apparently there is a crash test built into drkonqi but the binary never builds. Does anybody know how to implement this feature during the build process?
Darrell
Oddball request, but I need a
way to crash Trinity. :)
Apparently there is a crash test built into drkonqi but the binary never builds. Does anybody know how to implement this feature during the build process?
Enhancement patch submitted in bugzilla report 776. Rebuild kdebase, open a terminal, and run the crashtest binary to invoke drkonqi.
Darrell
I created bug report 769 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=769). Basically, on one particular computer I am able to get Ark to crash consistently.
Yesterday I started tinkering with building my packages with separate debug packages rather than building the debugging symbols into one package. I figure outside of the devs and packagers most end-users are not interested in that support. :(
Today on that same computer I installed new packages for kdelibs, kdebase, and kdeutils: six packages instead of three.
Now I can't get Ark to crash.
- I don't pretend to understand the nuances of debugging
symbols, but by splitting the debug symbols into a separate package, could I have resolved the bug? Does that make sense?
Anybody?
Darrell
If you need Trinity to crash just use kickoff, it should crash immediately On Jan 1, 2012 1:03 PM, "Darrell Anderson" humanreadable@yahoo.com wrote:
I created bug report 769 (
http://bugs.pearsoncomputing.net/show_bug.cgi?id=769).
Basically, on one particular computer I am able to get Ark to crash consistently.
Yesterday I started tinkering with building my packages with separate debug packages rather than building the debugging symbols into one package. I figure outside of the devs and packagers most end-users are not interested in that support. :(
Today on that same computer I installed new packages for kdelibs, kdebase, and kdeutils: six packages instead of three.
Now I can't get Ark to crash.
- I don't pretend to understand the nuances of debugging
symbols, but by splitting the debug symbols into a separate package, could I have resolved the bug? Does that make sense?
Anybody?
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I created bug report 769 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=769). Basically, on one particular computer I am able to get Ark to crash consistently.
Yesterday I started tinkering with building my packages with separate debug packages rather than building the debugging symbols into one package. I figure outside of the devs and packagers most end-users are not interested in that support. :(
Today on that same computer I installed new packages for kdelibs, kdebase, and kdeutils: six packages instead of three.
Now I can't get Ark to crash.
- I don't pretend to understand the nuances of debugging
symbols, but by splitting the debug symbols into a separate package, could I have resolved the bug? Does that make sense?
Anybody?
Calvin, grab some coffee to get some caffeine. :) I solved that particular problem --- I submitted a patch to build crashtest in kdebase/drkonqi. :). The crashtest executable works great, by the way.
I want to know whether having separate debugging packages could have solved the Ark bug. Makes no sense to me but perhaps you developer crackerjacks know better. :)
Darrell
On Fri, 30 Dec 2011 15:32:37 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
Oddball request, but I need a way to crash Trinity. :)
I created bug report 769 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=769). Basically, on one particular computer I am able to get Ark to crash consistently.
Yesterday I started tinkering with building my packages with separate debug packages rather than building the debugging symbols into one package. I figure outside of the devs and packagers most end-users are not interested in that support. :(
Today on that same computer I installed new packages for kdelibs, kdebase, and kdeutils: six packages instead of three.
Now I can't get Ark to crash.
$ killall -SEGV ark
- I don't pretend to understand the nuances of debugging symbols,
but by splitting the debug symbols into a separate package, could I have resolved the bug? Does that make sense?
- I need a way to crash something in Trinity so I can test my split
packages. I have browsed through the bugzilla and could not find anything that was repeatable here. Would someone please suggest a way to test the Dr. Konqi crash handler so I can generate a backtrace? My request is not related to point 1 above --- I just want to test whether my new package scheme is working and I need a way to verify I can generate a backtrace in Trinity. Perhaps there is a built-in easter egg or something that can do just that?
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I created bug report 769 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=769).
Basically, on
one particular computer I am able to get Ark to crash
consistently.
Yesterday I started tinkering with building my
packages with separate
debug packages rather than building the debugging
symbols into one
package. I figure outside of the devs and packagers
most end-users
are not interested in that support. :(
Today on that same computer I installed new packages
for kdelibs,
kdebase, and kdeutils: six packages instead of three.
Now I can't get Ark to crash.
$ killall -SEGV ark
Thanks, but that is not what I meant. :) I did not mean I want Ark to crash. I meant I no longer witness Ark crashing after installing my separate debugging symbols packages. To me, there should be no difference and Ark should still crash.
Possibly there was something wrong with my original all-in-one package. I don't know. The challenge now is I don't know whether the original Ark bug is valid or whether my debugging symbol packaging was the problem.
Darrell
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson