15 Aug
2013
15 Aug
'13
5:01 p.m.
I created a patch and am compiling as I write. Here is
the patch.
Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is
actually correct too.
Now to test the crash patch....
Darrell
15 Aug
15 Aug
5:07 p.m.
New subject: [trinity-devel] tdelibs FTBFS
On Friday 16 of August 2013 02:01:26 Darrell Anderson wrote:
Good job. Just one mistake - was not included "ConfigureChecks.cmake". Now I
test build on my local builder => I will soon approve it.
Slavek
--
I created a
patch and am compiling as I write. Here is the patch.
Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is
actually correct too.
Now to test the crash patch....
Darrell
6:07 p.m.
New subject: [trinity-devel] tdelibs FTBFS
On Friday 16 of August 2013 02:07:24 Slávek Banko wrote:
On Friday 16 of August 2013 02:01:26 Darrell Anderson
wrote:
Good job. Just one mistake - was not included "ConfigureChecks.cmake". Now
I test build on my local builder => I will soon approve it.
Slavek
A second mistake - ${BACKTRACE_LIBRARY} should be instead of bfd, not both.
For me successfully tested builds for both variants - with and without
backtrace handler.
However, there is still good objection from Fat-Zer... It would be good to
find a consensus soon, because the current situation leads to FTBFS.
Slavek
--
I created
a patch and am compiling as I write. Here is the patch.
Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is
actually correct too.
Now to test the crash patch....
Darrell 
7:07 p.m.
New subject: [trinity-devel] tdelibs FTBFS
2013/8/16 Slávek Banko <slavek.banko(a)axis.cz>
On Friday 16 of August 2013 02:07:24 Slávek Banko
wrote:
Here is propoused patch which checks if demangle.h is present.
I consider the print_trace() and all backtrace_symbol.c as a temporary
debug crutch. Am I wrong?
Tim, what are benefits of your print_trace() comparing to e.g. kdBacktrace
or generic backtrace()?
On Friday 16 of August 2013 02:01:26 Darrell
Anderson wrote:
Good job. Just one mistake - was not included "ConfigureChecks.cmake".
Now
I created
a patch and am compiling as I write. Here is the patch.
Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is
actually correct too.
Now to test the crash patch....
Darrell I test build on my local builder => I will
soon approve it.
Slavek
A second mistake - ${BACKTRACE_LIBRARY} should be instead of bfd, not both.
For me successfully tested builds for both variants - with and without
backtrace handler.
However, there is still good objection from Fat-Zer... It would be good to
find a consensus soon, because the current situation leads to FTBFS.
Slavek
--
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
7:09 p.m.
New subject: [trinity-devel] tdelibs FTBFS
2013/8/16 Fat-Zer <fatzer2(a)gmail.com>
Here is propoused patch which checks if demangle.h is
present.
Darrell, I have demangle.h on my system, so it's up to you to test it.
I consider the print_trace() and all backtrace_symbol.c as a temporary
debug crutch. Am I wrong?
Tim, what are benefits of your print_trace() comparing to e.g. kdBacktrace
or generic backtrace()?
8:20 p.m.
New subject: [trinity-devel] tdelibs FTBFS
2013/8/16 Slávek Banko <slavek.banko(a)axis.cz>
The new routine prints a stack trace that is very close to gdb's output,
complete with line numbers, whereas the other routines leave off critical
information which then makes debugging very difficult.
Either way, you are correct--the code section in question is only
activated when debugging is turned on at compile time (#undef NDEBUG in
tdeioslavebase.cpp). Furthermore, the output is logged to
~./xsession-errors as text, not via a popup kcrash dialog.
Tim
Tim
On Friday 16 of August 2013 02:07:24 Slávek
Banko wrote:
Here is propoused patch which checks if demangle.h is present.
I consider the print_trace() and all backtrace_symbol.c as a temporary
debug crutch. Am I wrong?
Tim, what are benefits of your print_trace() comparing to e.g. kdBacktrace
or generic backtrace()? On Friday 16 of August 2013 02:01:26 Darrell
Anderson wrote:
Now
>I created a patch and am compiling as I
write. Here is the patch.
>Please review!
Slavek,
The patch did not cause any build failures. Hopefully the patch is
actually correct too.
Now to test the crash patch....
Darrell
Good job. Just one mistake - was not included "ConfigureChecks.cmake". I test build on my local builder => I will
soon approve it.
Slavek
A second mistake - ${BACKTRACE_LIBRARY} should be instead of bfd, not
both.
For me successfully tested builds for both variants - with and without
backtrace handler.
However, there is still good objection from Fat-Zer... It would be good
to
find a consensus soon, because the current situation leads to FTBFS.
Slavek
--
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
9:13 p.m.
New subject: [trinity-devel] tdelibs FTBFS
2013/8/16 Timothy Pearson <kb9vqf(a)pearsoncomputing.net>
The new routine prints a stack trace that is very
close to gdb's output,
complete with line numbers, whereas the other routines leave off critical
information which then makes debugging very difficult.
Either way, you are correct--the code section in question is only
activated when debugging is turned on at compile time (#undef NDEBUG in
tdeioslavebase.cpp). Furthermore, the output is logged to
~./xsession-errors as text, not via a popup kcrash dialog.
Tim
ok... I suppose it would be nice to make it an another backend for
kdBacktrace. but before starting to I've got couple more questions:
Does it have some special requirements? e.g. debug information (splitted or
not) or source code installed?
Is there any library that implements it and provides higher-level API?
3929
days inactive
3929
days old
6 comments
4 participants
participants (4)
-
Darrell Anderson -
Fat-Zer -
Slávek Banko -
Timothy Pearson