Stephan == Stephan Bergmann sberg...@redhat.com writes:
Stephan Great, thanks. (So your idea would be to, in a second step, teach
Stephan ABRT to issue additional gdb commands besides backtrace in case the
Stephan trace contains __gnu_cxx::__verbose_terminate_handler, right?)
If that GCC bug
Tom I think it may be fixable in GCC.
I filed a GCC bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57487
You can CC yourself on it if you want to see what happens.
Tom
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
Stephan == Stephan Bergmann sberg...@redhat.com writes:
Stephan It would be cool if there were a way to see that message in the gdb
Stephan backtrace. Like __gnu_cxx::__verbose_terminate_handler assembling the
Stephan message and then calling a not-optimized-away helper function with the
David == David Ostrovsky d.ostrov...@gmx.de writes:
David The only question is now, how to skip the manual sourcing of
David libpython.py? If i understand it right, it happens automagically on
David Fedora?
Yes, Fedora installs
/usr/lib/debug/usr/lib64/libpython2.7.so.1.0.debug-gdb.py
Michael == Michael Stahl mst...@redhat.com writes:
CCing David Malcolm.
Michael (gdb) py-bt
I just wanted to mention here that Phil Muldoon is working on a frame
filter patch series that is basically pretty printing for stack
frames. With this in place you'll no longer need a special command
Tom I think it isn't possible in general. When an exception is thrown, I
Tom think all that can really be determined is the next catch point.
Michael This would be perfect. Explicit rethrows are relatively rare in
Michael our code, however it is completely normal to have code that we
Michael
Tom == Tom Tromey tro...@redhat.com writes:
Tom The various low-level exception-related functions, like __cxa_throw,
Tom treat the exception object as a void *. However, the value of this
Tom seems to change depending on the throw point. It's clear that this
Tom can't always be the argument
Michael == Michael Meeks michael.me...@suse.com writes:
Michael The basic debugging experience in these an exception broke
Michael something flows is that we get an exception thrown that
Michael ultimately ends up in a pathalogical situation - an abort, or
Michael some similar horrible badness.
Lubos == Lubos Lunak l.lu...@suse.cz writes:
Tom Is there something we could do to improve it?
Lubos I don't know how much control gdb over exception handling has,
Lubos so I don't know :).
:-)
FWIW we have the same problem in reverse: the gdb group at Red Hat is,
among other things, tasked
Lubos == Lubos Lunak l.lu...@suse.cz writes:
Lubos This could be very useful ('catch throw' is so cumbersome in
Lubos gdb),
Is there something we could do to improve it?
Lubos but I think the first thing to check is if it would
Lubos actually work. Last time I checked, recent features like
Noel == Noel Grandin noelgran...@gmail.com writes:
Noel Would be nice if gdb could actually do catch throw XXXException like
Noel the documentation says - perhaps the documentation was modified
Noel prematurely?
Yeah, I think it was.
The docs have been changed to reflect reality.
Actually
Michael == Michael Meeks michael.me...@suse.com writes:
MichaelIIWY I'd insert a break-point thus:
Michaelbreak unotxdoc.cxx:12345
Michaelwhere 12345 is the line-number of the lcl_ function that
Michael is most likely inlined (as static 's tend to be) which usually
Joel == Joel Madero jmadero@gmail.com writes:
Joel I've finally gotten comfortable with gdb as far as break points and
Joel what not. What I want to know is if there is a way for me to see all
Joel symbols called during a given run of soffice. Getting a log that shows
Joel every symbol
Michael == Michael Meeks michael.me...@suse.com writes:
Michael #2 0xb784d6f1 in SfxFrame::Create (i_rFrame=warning: RTTI symbol not
Michael found for class 'framework::Frame'
Michael warning: RTTI symbol not found for class 'framework::Frame'
Michael warning: RTTI symbol not found for class
Christina == Christina Roßmanith chrrossman...@gmx.de writes:
Christina You mean if I compile only a subset of modules with
Christina dbglevel0?
Maybe. I'm not really sure. I'd like to find a simple reproducer so I
could find out.
Christina I'm getting the RTTI messages as well but can't
Michael == Michael Meeks michael.me...@suse.com writes:
Michael I guess we should add an 'easy hack' for some gdb / python
Michael goodness to expand / annotate Basic stack frames prettily in
Michael the debugger too ;-) [ we can but wish ].
FWIW Phil Muldoon is working on a new gdb/Python
Lubos == Lubos Lunak l.lu...@suse.cz writes:
Lubos As a sidenote, this gave me an interesting idea that I want to
Lubos try somewhen. It might be actually helpful to explicitly not
Lubos have debug info about macros and enclose bodies of some functions
Lubos like uno::Reference::operator-() or
Lionel == Lionel Elie Mamane lio...@mamane.lu writes:
Tom In a recent-enough GCC (I don't know if it made 4.6, but anyway I
Tom think it is in Fedora 16), there is a GNU extension to how macro
Tom information is represented. This extension greatly reduces the size
Tom of the macro information.
Stephan == Stephan Bergmann sberg...@redhat.com writes:
Stephan On 11/30/2011 05:37 PM, Lionel Elie Mamane wrote:
Any opinion about this patch? I have it in my local repo, and it helps
me when running under gdb, as gdb now knows about macros!
Stephan Would -ggdb3 excessively increase object
Michael == Michael Stahl
mstahl-h+wxahxf7alqt0dzr+a...@public.gmane.org writes:
Mark Wielaard pointed out this note to me.
Feel free to CC 'arc...@sourceware.org' on hacks like this, we're
interested in hearing about them and to find out what developers need
from gdb.
Michael since my
I'm re-sending this note... I sent it yesterday via gmane, but I guess
this list is configured for moderation even in that situation; so today
I joined.
Mark Wielaard pointed out this note to me.
Feel free to CC 'arc...@sourceware.org' on hacks like this, we're
interested in hearing about them
Michael == Michael Stahl
mstahl-h+wxahxf7alqt0dzr+a...@public.gmane.org writes:
Michael have just found a great python command for GDB by Tom Tromey called
Michael info mutex:
Michael http://www.cygwin.com/ml/archer/2010-q3/msg00024.html
Michael looks very helpful for debugging a deadlock
Third time's the charm. Apologies if you've seen this a lot.
Mark Wielaard pointed out this note to me.
Feel free to CC 'arc...@sourceware.org' on hacks like this, we're
interested in hearing about them and to find out what developers need
from gdb.
Michael since my smoketest failed again
Norbert == Norbert Thiebaud nthieb...@gmail.com writes:
Norbert 1/ Are we sure that this behavior will be seen in a _released_ gcc ?
Norbert (not a rhetorical question, I'm a bit weary of chasing gcc trunk that
Norbert closely)
I believe so; or at least, this is definitely a bug in LibreOffice.
Noel I rolled up this patch and the previous one here
Noel
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c2a634416ba8f385c25c16cc52aeae6f68cab9db
I don't understand where these commits go.
I re-pulled in 'ure' (actually everywhere using ./g pull) but I don't
see that commit. I'm on
Miklos Yes, core.git. See
Miklos
http://wiki.documentfoundation.org/Development/Native_Build#Getting_the_sources
Miklos Background:
http://wiki.documentfoundation.org/Development/One_Git_Conversion
Thanks. I must have read some stale document before starting; but
unfortunately I don't recall
I tried building LibreOffice with svn trunk gcc.
It dies in soltools with:
Compiling: soltools/giparser/gi_list.cxx
In file included from ../inc/gi_list.hxx:33:0,
from
/home/tromey/Space/LibreOffice/bootstrap/soltools/giparser/gi_list.cxx:33:
../inc/st_list.hxx: In
I tried building LibreOffice with svn trunk gcc.
It dies in xml2cmp with:
Compiling: xml2cmp/source/xcd/xmlelem.cxx
In file included from ./xmlelem.hxx:38:0,
from
/home/tromey/Space/LibreOffice/bootstrap/clone/ure/xml2cmp/source/xcd/xmlelem.cxx:30:
./../support/list.hxx: In
I tried building LibreOffice with svn trunk gcc; though in this case the
bug seems to be a fairly generic include order problem.
The build dies in cosv with:
Compiling: cosv/source/strings/string.cxx
In file included from ../../inc/cosv/string.hxx:33:0,
from
I tried building LibreOffice with svn trunk gcc.
It dies in sax with:
In file included from
/home/tromey/Space/LibreOffice/bootstrap/sax/source/tools/fastserializer.cxx:33:0:
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/comphelper/sequenceasvector.hxx:
In instantiation
Tom == Tom Tromey tro...@redhat.com writes:
Tom I tried building LibreOffice with svn trunk gcc.
Tom It dies in sax with:
[...]
Tom The appended patch fixes this problem by adding a 'this-' qualifier.
Oops, I appended the wrong patch to this message. Here is the correct
patch.
I am not really
31 matches
Mail list logo
