[Libreoffice] [PATCH] fix soltools build with svn gcc
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 instantiation of 'DynamicList&
DynamicList::operator=(const DynamicList&) [with XY = GenericInfo]':
/home/tromey/Space/LibreOffice/bootstrap/soltools/giparser/gi_list.cxx:59:25:
required from here
../inc/st_list.hxx:298:10: error: 'push_back' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../inc/st_list.hxx:298:10: note: declarations in dependent base
'ST_List' are not found by unqualified lookup
../inc/st_list.hxx:298:10: note: use 'this->push_back' instead
../inc/st_list.hxx: In instantiation of 'void DynamicList::Insert(unsigned
int, XY* const&) [with XY = GenericInfo]':
/home/tromey/Space/LibreOffice/bootstrap/soltools/giparser/gi_list.cxx:234:1:
required from here
../inc/st_list.hxx:311:5: error: 'checkSize' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
../inc/st_list.hxx:311:5: note: declarations in dependent base
'ST_List' are not found by unqualified lookup
../inc/st_list.hxx:311:5: note: use 'this->checkSize' instead
The appended patch fixes this problem by adding 'this->' qualifiers.
This is contributed under the LGPLv3+/MPL.
Tom
diff --git a/soltools/inc/st_list.hxx b/soltools/inc/st_list.hxx
index 51f0a32..69b6943 100644
--- a/soltools/inc/st_list.hxx
+++ b/soltools/inc/st_list.hxx
@@ -295,7 +295,7 @@ DynamicList::operator=( const DynamicList & i_rList
)
it != i_rList.end();
++it )
{
- push_back( new XY(*(*it)) );
+ this->push_back( new XY(*(*it)) );
}
return *this;
}
@@ -308,7 +308,7 @@ DynamicList::Insert(unsigned pos, XY * const & elem_)
if ( pos > this->len )
return;
-checkSize(DynamicList::len+2);
+this->checkSize(DynamicList::len+2);
memmove( DynamicList::inhalt+pos+1, DynamicList::inhalt+pos,
(DynamicList::len-pos) * sizeof(XY*) );
this->inhalt[pos] = elem_;
this->len++;
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fix xml2cmp build with svn gcc
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 instantiation of 'void DynamicList::insert(unsigned int, XY* const&) [with XY = XmlElement]': /home/tromey/Space/LibreOffice/bootstrap/clone/ure/xml2cmp/source/xcd/xmlelem.cxx:263:1: required from here ./../support/list.hxx:229:5: error: 'checkSize' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ./../support/list.hxx:229:5: note: declarations in dependent base 'List' are not found by unqualified lookup ./../support/list.hxx:229:5: note: use 'this->checkSize' instead dmake: Error code 1, while making '../../unxlngx6.pro/obj/xmlelem.obj' The appended patch fixes this problem by adding a 'this->' qualifier. This is contributed under the LGPLv3+/MPL. Tom diff --git a/xml2cmp/source/support/list.hxx b/xml2cmp/source/support/list.hxx index 6de123e..e4e5361 100644 --- a/xml2cmp/source/support/list.hxx +++ b/xml2cmp/source/support/list.hxx @@ -226,7 +226,7 @@ DynamicList::insert(unsigned pos, XY * const & elem_) if ( pos > this->len ) return; -checkSize(this->len+2); +this->checkSize(this->len+2); memmove(this->inhalt[pos+1], this->inhalt[pos], (this->len-pos) * sizeof(XY*) ); this->inhalt[pos] = elem_; this->len++; ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fix cosv build
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 ../../inc/cosv/csv_precomp.h:39, from ../inc/precomp.h:32, from /home/tromey/Space/LibreOffice/bootstrap/clone/sdk/cosv/source/strings/string.cxx:29: ../../inc/cosv/stringdata.hxx: In instantiation of 'csv::StringData::StringData(const CHAR*, csv::StringData::size_type) [with CHAR = char, csv::StringData::size_type = long unsigned int]': /home/tromey/Space/LibreOffice/bootstrap/clone/sdk/cosv/source/strings/string.cxx:75:17: required from here ../../inc/cosv/stringdata.hxx:105:5: error: 'memcpy' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] /usr/include/string.h:44:14: note: 'void* memcpy(void*, const void*, size_t)' declared here, later in the translation unit dmake: Error code 1, while making '../../unxlngx6.pro/obj/string.obj' string.hxx includes , which declares memcpy, after cosv/stringdata.hxx. Moving earlier fixes the problem. This is contributed under the LGPLv3+/MPL. Tom diff --git a/cosv/inc/cosv/string.hxx b/cosv/inc/cosv/string.hxx index 08b1220..8f249f9 100644 --- a/cosv/inc/cosv/string.hxx +++ b/cosv/inc/cosv/string.hxx @@ -30,9 +30,9 @@ #define COSV_STRING_HXX // USED SERVICES +#include #include #include -#include #include #include ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] o3tl build -vs- svn gcc
I tried building LibreOffice with svn trunk gcc.
It dies in o3tl with:
In file included from
/home/tromey/Space/LibreOffice/bootstrap/o3tl/qa/test-vector_pool.cxx:8:0:
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/o3tl/vector_pool.hxx:
In instantiation of ‘std::ptrdiff_t o3tl::detail::simple_pool_impl::store(const ValueType&) [with ValueType = int, Container =
std::vector::type,
std::allocator::type> >, std::ptrdiff_t =
long int]’:
/home/tromey/Space/LibreOffice/bootstrap/o3tl/qa/test-vector_pool.cxx:40:45:
required from here
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/o3tl/vector_pool.hxx:68:21:
error: ‘push_back’ was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation [-fpermissive]
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/o3tl/vector_pool.hxx:68:21:
note: declarations in dependent base
‘std::vector::type,
std::allocator::type> >’ are not found by
unqualified lookup
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/o3tl/vector_pool.hxx:68:21:
note: use ‘this->push_back’ instead
The appended patch fixes this problem by adding a 'this->' qualifier.
This is contributed under the LGPLv3+/MPL.
Tom
diff --git a/o3tl/inc/o3tl/vector_pool.hxx b/o3tl/inc/o3tl/vector_pool.hxx
index 6ef4e96..28299f0 100644
--- a/o3tl/inc/o3tl/vector_pool.hxx
+++ b/o3tl/inc/o3tl/vector_pool.hxx
@@ -65,7 +65,7 @@ namespace o3tl
}
else
{
-push_back(value_type(rCopy));
+this->push_back(value_type(rCopy));
return this->size()-1;
}
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] sax build -vs- svn gcc
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 of ‘void
comphelper::SequenceAsVector::operator<<(const
com::sun::star::uno::Sequence&) [with TElementType = int]’:
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/comphelper/sequenceasvector.hxx:111:13:
required from
‘comphelper::SequenceAsVector::SequenceAsVector(const
com::sun::star::uno::Sequence&) [with TElementType = int]’
/home/tromey/Space/LibreOffice/bootstrap/sax/source/tools/fastserializer.cxx:468:55:
required from here
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/comphelper/sequenceasvector.hxx:150:17:
error: ‘push_back’ was not declared in this scope, and no declarations were
found by argument-dependent lookup at the point of instantiation [-fpermissive]
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/comphelper/sequenceasvector.hxx:150:17:
note: declarations in dependent base ‘std::vector >’
are not found by unqualified lookup
/home/tromey/Space/LibreOffice/bootstrap/solver/350/unxlngx6.pro/inc/comphelper/sequenceasvector.hxx:150:17:
note: use ‘this->push_back’ instead
The appended patch fixes this problem by adding a 'this->' qualifier.
This is contributed under the LGPLv3+/MPL.
Tom
diff --git a/o3tl/inc/o3tl/vector_pool.hxx b/o3tl/inc/o3tl/vector_pool.hxx
index 6ef4e96..28299f0 100644
--- a/o3tl/inc/o3tl/vector_pool.hxx
+++ b/o3tl/inc/o3tl/vector_pool.hxx
@@ -65,7 +65,7 @@ namespace o3tl
}
else
{
-push_back(value_type(rCopy));
+this->push_back(value_type(rCopy));
return this->size()-1;
}
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] sax build -vs- svn gcc
>>>>> "Tom" == Tom Tromey 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 sure where this file comes from. From what I can tell it isn't in git. Tom --- sequenceasvector.hxx.~1~2011-08-10 08:25:19.179720480 -0600 +++ sequenceasvector.hxx2011-08-10 11:48:05.404703517 -0600 @@ -147,7 +147,7 @@ const TElementType* pSource = lSource.getConstArray(); for (sal_Int32 i=0; ipush_back(pSource[i]); } //--- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] fix xml2cmp build with svn gcc
> "Norbert" == Norbert Thiebaud 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. 'checkSize' is inherited from a dependent base class, so it must be qualified. See, e.g.: http://www.parashift.com/c++-faq-lite/templates.html#faq-35.19 Norbert> 2/ I am not well equipped to apply in-lined patch like that (I use Norbert> gmail as main mailbox for this dev-list... so it is cut-and-paste with Norbert> horror stories about line wrapping and all) Norbert> could you use git format-patch to generate patches and attach them Norbert> (git format-patch as the added benefit that I don't have to type Norbert> --author="Your Name -m "a nice commit message that _I_ Norbert> would have to come up with" but instead cat Norbert> | git am I will do that in the future, thanks for the tip. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] fix xml2cmp build with svn gcc
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 'master', should I be using some other branch? Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] fix xml2cmp build with svn gcc
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 what. I will start over. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gdb support for exceptions (Re: using backtrace() in exception throwing?)
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> simply don't understand and/or follow - whereby we do:
Unfortunately, it is even worse than I made it out to be. The "next
catch point" also includes the spots where unwinding pauses to invoke
destructors. So, at the lowest level you can't easily associate a
"throw" with a "catch" that you would see in the source. You can only
see to spot that calls the next destructor.
If you're interested you can see this in action by breaking at the
"libgcc:unwind" probe point (or equivalently _Unwind_DebugHook but then
you have to do argument decoding by hand), then "disassem $_probe_arg1".
That will show you the assembly for where you're about to unwind to.
("catch catch" and "catch throw" hook into somewhat higher-level
exception functions in libstdc++, which is why they don't stop at
destructors; but this code doesn't know about the details and just
defers to the lower-level unwinder.)
I thought a bit about whether we could fix the lower levels to expose
the information we'd like, but I couldn't think of a good way.
Tom> catch catch [REGEXP]
Tom> catch throw [REGEXP]
Tom> catch rethrow [REGEXP]
Michael> This is really nice; the ability to hide many of the "two
Michael> dozen+" expected exceptions in some way be really
Michael> useful. Unfortunately these are often of quite generic types
Michael> :-)
Yeah, that makes it harder.
If they carry any identifying markers, you can use two of the features
in tandem to filter. For example:
catch throw TheExceptionType if $_exception.field == 23
This would filter by type and then do some additional checking of the
identity of the exception.
If they don't carry identifying markers -- if it were me, I guess I
would add something to make debugging simpler.
Michael> Tor suggested on IRC some way of ignoring specific exception throwing
Michael> sites which tend to creep into the code over time and need tackling.
Michael> Being able to say: catch throw ignore - which would ignore the last
Michael> thrown exception site would be really lovely ;-)
This sort of thing is reasonably easy to do in Python.
Fedora has had a $_caller_is function in its gdb for a while (not sure
why we haven't upstreamed this yet, probably just nobody got around to
it yet). This function was actually my motivation for getting into gdb
hacking and working on Python in gdb -- I wanted to be able to filter
breakpoints according to caller, without a lot of hassle.
I've appended it for convenience. I'll file a bug to remind us to
upstream this.
You would use it like:
catch throw if !$_caller_is('some_thrower_to_ignore')
You could wrap this up in a Python command to add "&& !$_caller_is..."
to existing breakpoint conditions, or a LibreOffice-specific "catch
throw"-like command which pre-ignores uninteresting call sites, or etc.
Michael> Is any of that useful ? - really looking forward to getting a
Michael> new libstdc++ etc. with your fixes in a few months :-)
An optimist, I see :)
Actually, I assume all the patches will go in reasonably soon, but
there's a pretty long lag until the new stuff is deployed all over,
unless you're willing to build your gcc.
Please feel free to CC me on gdb questions and suggestions.
I'm very interested in your feedback.
Tom
# Caller-is functions.
# Copyright (C) 2008 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see
Re: GDB - Can I See Every Symbol Called?
> "Michael" == Michael Meeks writes: Michael>IIWY I'd insert a break-point thus: Michael>break unotxdoc.cxx:12345 Michael>where 12345 is the line-number of the lcl_ function that Michael> is most likely inlined (as static 's tend to be) which usually Michael> confuses gdb nicely ;-) [ when compiled with -g -O2 etc. ]. "break inlinefunction" should work ok with a recent-enough version of gdb. Older versions needed "break file:line". Even older versions just didn't work at all. If you know of bugs here, please report them. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: GDB - Can I See Every Symbol Called?
> "Joel" == Joel Madero 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 called would allow me to compare to runs of libreoffice, Joel> one where I push "Ok" the other where I push "Cancel". It isn't really possible with gdb. I'd like it to be -- I wish "rbreak *" would DTRT -- but unfortunately some parts of gdb aren't as scalable as I'd like, and nobody has yet put the work into fixing them. I've personally never actually wanted to do this, but if I were going to tackle it I would either look at using ltrace, systemtap, or writing a valgrind skin (perhaps one exists already, I don't know). Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: using backtrace() in exception throwing?
> "Lubos" == Lubos Lunak 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
Lubos> -fvisibility make backtrace() very often generate call traces
Lubos> that are next to useless.
There are a few other approaches that are possible on Linux.
There is one that is part of GCC, libbacktrace.
It is its own library, but part of the GCC tree; so you'd have to
extract it.
Jan is also writing one based on elfutils. It is in elfutils git but
not merged to master yet.
Also it can be done using the existing unwinder data, which already
exists for exception handling. This is the approach libgcj took.
Specifically, it used this data to construct the list of PC values and
stash this in the exception; this was then transformed when actually
printing an exception. The code in libgcj is a bit hairier than you
might need, since it had to handle interpreter and libffi frames
specially. You could probably adapt it.
Tom
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: using backtrace() in exception throwing?
> "Noel" == Noel Grandin 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 implementing the feature is on our to-do list: http://sourceware.org/bugzilla/show_bug.cgi?id=13588 Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
> "Michael" == Michael Stahl 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 -- with appropriate support from Python, you'll be able to see interpreted frames interleaved with the low-level C frames. This series is nearing final review now and should appear in gdb 7.7, later this year. I think we're planning to rewrite the existing "py-bt" code into frame filter form ourselves. Michael> unfortunately one thing that i haven't found how to do is setting a Michael> breakpoint in the python code from gdb... the best i've found is a lame Michael> workaround of inserting a statement into the python code to send Michael> yourself a signal, which is, well, a lame workaround: >> os.kill(os.getpid(), signal.SIGUSR1) Michael> i wonder if it would be possible to easily add something to gdb to make Michael> the python debugging a bit more seamless? Eventually we'd like to have more full support for "mixed" interpreter and C debugging. However this is a ways off. Meanwhile, you can do it, if you know some details about the interpreter implementation. It is just a question of setting a breakpoint at the right spot in the C code, with the right condition so that it only fires for your particular bit of code. Maybe David can say how. Perhaps the "function__entry" SDT probe point is apropos. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gdb support for exceptions (Re: using backtrace() in exception throwing?)
> "Stephan" == Stephan Bergmann 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 Stephan> message as argument, which in turn calls fputs and abort (though I Stephan> notice that __verbose_terminate_handler currently "assembles" messages Stephan> through multiple calls to fputs, which saves it from malloc hassles). I think it may be fixable in GCC. Right now the issue is that 't' is optimized away; but in a local build I can see: (gdb) info local terminating = true t = 0x601060 <_ZTIi@@CXXABI_1.3> ... which, while not completely readable, is at least transformable with c++filt or "maint demangle". I pinged a local GCC hacker, I'll let you know if he thinks this is fixable. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gdb support for exceptions (Re: using backtrace() in exception throwing?)
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 http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gdb support for exceptions (Re: using backtrace() in exception throwing?)
> "Stephan" == Stephan Bergmann 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 is fixed, then the existing "bt full" would capture the type information. The info would appear in a mangled form, but it is trivial to run that through c++filt. Like in my example: t = 0x601060 <_ZTIi@@CXXABI_1.3> -> $ c++filt _ZTIi typeinfo for int Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: claims of python unit test un-debugability considered somewhat exaggerated
> "David" == David Ostrovsky 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 (e.g.) as a "hook" file for gdb to load. And, it sets up gdb's trusted auto-load path to allow this. See: http://sourceware.org/gdb/current/onlinedocs/gdb/Python-Auto_002dloading.html#Python-Auto_002dloading Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gdb support for exceptions (Re: using backtrace() in exception throwing?)
> "Lubos" == Lubos Lunak 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 with improving the C++ debugging experience.
However, most of us don't actually debug C++ programs on a regular
basis. We do know some issues, via bugzilla and other discussions, but
I feel sure we are also missing things.
Lubos> What I was refering to was the problem that if a catch block
Lubos> catches an exception, it's often difficult to find out where it
Lubos> actually came from. Using 'catch catch' doesn't show where it
Lubos> originated (unless I missed a non-obvious way). And if the
Lubos> exception propagated out of complex nesting of function calls,
Lubos> then 'catch throw' may trigger a number of times for exceptions
Lubos> that will be handled elsewhere.
Solving this in general looks tricky to me. I am not really sure how to
do it, but I will think about it some more.
The basic issue is that if 'catch throw' triggers multiple times for the
same exception, then it seems that there must be code that catches the
exception and then throws it again:
try { } catch (blah) { throw blah; }
As opposed to a true re-throw:
try { } catch (blah) { throw; }
AFAIK re-throws are currently not caught, see
http://sourceware.org/bugzilla/show_bug.cgi?id=12824
I'm not sure whether it is possible to easily detect whether "throw x"
is throwing some object which has already been thrown.
Hopefully I'm misunderstanding the problem :)
Meanwhile, I did whip up a quick-and-dirty Python-based approach. It
adds a new "track-throws" command. This command installs a breakpoint
that records the point of the most recent "throw". Then you can examine
the result with "info last-throw".
Here it is in action:
(gdb) source track_throw.py
(gdb) track-throws
Breakpoint 1 at 0x400910
(gdb) catch catch
Catchpoint 2 (catch)
(gdb) run
[...]
Catchpoint 2 (exception caught), __cxxabiv1::__cxa_begin_catch (
exc_obj_in=0x602070) at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:41
41 {
(gdb) info last-throw
Last exception thrown at file
../../../archer/gdb/testsuite/gdb.cp/nextoverthrow.cc, line 36
"track-throws" makes the breakpoint it installs user-visible so you can
disable the feature simply by deleting the breakpoint.
I'm curious to know if this is useful to you.
Tom
import gdb
last_sal = None
throw_bp = None
class ThrowTracker(gdb.Breakpoint):
def __init__(self):
gdb.Breakpoint.__init__(self, '__cxa_throw')
def stop(self):
global last_sal
frame = gdb.newest_frame().older()
last_sal = frame.find_sal()
return False
class TrackThrows(gdb.Command):
def __init__(self):
gdb.Command.__init__(self, 'track-throws', gdb.COMMAND_BREAKPOINTS)
def invoke(self, arg, from_tty):
global throw_bp
if throw_bp is None or not throw_bp.is_valid():
# Still no good way to create a pending breakpoint from
# Python.
save = gdb.parameter('breakpoint pending')
gdb.execute('set breakpoint pending on', to_string = True)
throw_bp = ThrowTracker()
if save is None:
arg = 'auto'
elif save:
arg = 'on'
else:
arg = 'off'
gdb.execute('set breakpoint pending %s' % arg, to_string = True)
class InfoThrow(gdb.Command):
def __init__(self):
gdb.Command.__init__(self, 'info last-throw', gdb.COMMAND_BREAKPOINTS)
def invoke(self, arg, from_tty):
global last_sal
if last_sal is not None:
filename = last_sal.symtab.filename
line = last_sal.line
print "Last exception thrown at file %s, line %d" % (filename, line)
else:
print "No previous exception seen"
TrackThrows()
InfoThrow()
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Gdb support for exceptions (Re: using backtrace() in exception throwing?)
> "Michael" == Michael Meeks 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. At that point the most
Michael> interesting thing is not the catcher - which usually ends up
Michael> being utterly random - but the last guy that threw the
Michael> exception. So then as Lubos says comes the knotty job of trying
Michael> to put a breakpoint on the -one- exception that ends up being
Michael> caught where we are now [ and that of course requires
Michael> re-running, and inevitably we throw dozens of exceptions in the
Michael> normal case ].
Thanks. This kind of discussion is very helpful to me.
This problem is a bit tricky.
The various low-level exception-related functions, like __cxa_throw,
treat the exception object as a "void *". However, the value of this
seems to change depending on the "throw" point. It's clear that this
can't always be the argument to throw, due to scalar and object throws.
So I wonder what exactly it refers to. I'll have to dig a bit deeper to
see how all this code really works.
Anyway, this makes tracking backward from std::terminate to the original
throw point more difficult.
It helps a bit to install the libstdc++ debuginfo. Then at least you
can dig into some of the details. However, due to optimization, even
with the improvements in newer version of gcc, this turns out to be less
than perfect.
I tried this out to see what it was like. It is kind of awful! At
least, I had to dig around through several frames of libstdc++ to find
the object that lead to std::terminate being called:
terminate called after throwing an instance of 'char const*'
Program received signal SIGABRT, Aborted.
0x003be3036285 in __GI_raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) up
#1 0x003be3037b9b in __GI_abort () at abort.c:91
91raise (SIGABRT);
(gdb) up
#2 0x003be80bbc5d in __gnu_cxx::__verbose_terminate_handler ()
at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
95 abort();
(gdb) up
#3 0x003be80b9e16 in __cxxabiv1::__terminate (handler=)
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:40
40handler ();
(gdb) up
#4 0x003be80b9e43 in std::terminate ()
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:50
50__terminate (__terminate_handler);
(gdb) up
#5 0x003be80b9f3e in __cxxabiv1::__cxa_throw (obj=0x601090,
tinfo=, dest=)
at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:83
83std::terminate ();
At this point I can do:
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) cond 1 obj == 0x601090
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
[Inferior 25299 exited]
Starting program: /tmp/r
warning: failed to reevaluate condition for breakpoint 1: No symbol "obj" in
current context.
warning: failed to reevaluate condition for breakpoint 1: No symbol "obj" in
current context.
warning: failed to reevaluate condition for breakpoint 1: No symbol "obj" in
current context.
Catchpoint 1 (exception thrown), __cxxabiv1::__cxa_throw (obj=0x601090, tinfo=
0x600a60, dest=0) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:70
70header->exc.unexpectedHandler = __unexpected_handler;
Ignore the warnings; I'm not sure what they are about, but I will file a
bug.
... but all this still fails if you insert a "manual re-throw" like
"throw x;" into the call chain. At that point it gets really messy :(
Michael> Really nice ! though of course - having a full stack trace
Michael> would make that very substantially more useful.
This is reasonably easy to implement. It may be expensive. I've
appended a version that does this... well, it lists file name and line
number for all the frames. If you want to get a really full stack
trace, capturing the arguments and locals, then you would have to do
more work.
Michael> Even better than this would (perhaps) be a "break inside thrower that
Michael> is caught here" type breakpoint - that we could invoke to land us in
Michael> whatever code is going to throw as it does that [ and before it started
Michael> all the magic cleanup / unwinding work ]. That is - assuming that it's
Michael> possible for the code to know (at that point) where it will ultimately
Michael> end up (? ;-)
I think it isn't possible in general. When an exception is thrown, I
think all that can really be determined is the next catch point.
What this means is that if you have a series of throws and re-throws,
winding up at some "catch", then the best you could do is stop at the
re-throw that leads to that catch.
Does that make sense?
Like:
void doit()
{
throw "hi";
}
void dd2()
{
try {
doit
Re: Gdb support for exceptions (Re: using backtrace() in exception throwing?)
>>>>> "Tom" == Tom Tromey 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 to throw, due to scalar and object throws. Tom> So I wonder what exactly it refers to. I'll have to dig a bit deeper to Tom> see how all this code really works. [...] Tom> It seems like it would be nice if gdb exposed some kind of convenience Tom> variable so that "catch catch" and "catch throw" could be conditional on Tom> the thrown object without needing the libstdc++ debuginfo. [...] Tom> This may require some libstdc++ change, perhaps a probe point. I did some more digging here and wrote a few patches. When throwing an exception, the compiler arranges to allocate an internal exception object with enough extra space for the exception passed to "throw". Then it copy-constructs from the thrown object into this space and it records the object's type_info into the internal exception object. I added some SDT probes to libstdc++ to expose this information more nicely (there's really no good way to do it in all cases right now, even with debuginfo installed, as a couple of the probes are mid-function). So now I can: (gdb) catch throw Catchpoint 1 (throw) (gdb) r Starting program: /home/tromey/Space/SecondArcher/build/gdb/testsuite/gdb.cp/exception [... loads of gunk ...] Catchpoint 1 (exception thrown), __cxxabiv1::__cxa_throw (obj=0x601090, tinfo=0x600e60 , dest=0x0) at ../../../../gcc/libstdc++-v3/libsupc++/eh_throw.cc:63 63PROBE2 (throw, obj, tinfo); (gdb) p $_exception $1 = 13 Note that the exception variable automatically has the right type: (gdb) up #1 0x00400873 in foo (i=20) at ../../../archer/gdb/testsuite/gdb.cp/exception.cc:28 28 throw (int) 13; So, cool. The bad news is, since this requires a libstdc++ patch, even once I get everything tidied up and approved and committed, it is going to be a while before you can use it, unless you're willing to build your own gcc and gdb. Tom> If we had the convenience variable mentioned above, and if LibreOffice Tom> has a relatively simple "exception identity" measure (e.g., if you only Tom> throw pointers, you can just compare them with ==), then it could Tom> perhaps be done by: break at the losing catch, make a conditional "catch Tom> throw", then re-run. This does turn out to be a tricky bit. gdb generally mimics the source language, so things like: cond 5 $_exception == 23 ... will fail if some exception thrown is not actually comparable to 23. I'm investigating some options here. Maybe a more-magical "===" operator, or maybe a Python convenience function like: cond 5 $_dwim_equals ($_exception, 23) I also implemented a way to filter exception catches by name: catch catch [REGEXP] catch throw [REGEXP] catch rethrow [REGEXP] That will help the above problem a bit, you can do: catch catch int if $_exception == 23 I think all this should help with the problems that started this thread. Insight, advice, ideas -- send them my way. thanks, Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] buglet in 1ec7b6a4 (?)
Commit 1ec7b6a4 changed autogen.sh to create autogen.lastrun only if some arguments were provided when invoking autogen.sh. However, Makefile still has: Makefile: autogen.lastrun configure.in ooo.lst.in set_soenv.in Makefile.in ./autogen.sh This means that my build fails with: $ make make: *** No rule to make target `autogen.lastrun', needed by `Makefile'. Stop. I don't understand the need for 1ec7b6a4, so I didn't unpatch it. Touching the file seems to be working ok as a workaround. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gdb: info mutex
>>>>> "Michael" == Michael Stahl >>>>> 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: Just be warned, it is a bit broken. It has some heuristics to see when a thread is attempting to acquire a lock, but these do not always yield the correct answer. Still, it shouldn't be too misleading, as you can always dig around manually to verify what it says. Also I think you need glibc debuginfo installed for it to work at all. We hope to write a better version, replacing the heuristics with hidden breakpoints on sdt.h probe points in glibc. I think the probes might be there (in Fedora, but probably not anywhere else, as upstream rejected the probes), but we haven't written the gdb side yet. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gdb: catching exceptions...
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 today, i've distracted myself a bit Michael> with GDB Python scripting, the result of which is a command that can Michael> break when an exception is thrown, but only if a certain function Michael> (which is given as parameter) is on the stack. Nice. Michael> seems to work, but it is quite slow: finding the smoketest exception Michael> in SfxBaseModel::getTitle takes GDB 4 minutes of CPU time. Michael> now probably somebody will tell me that i'm too stupid to RTFM and Michael> there is a much simpler way to do this :) There isn't a simpler way right now. You could try to do it by having a breakpoint on the function you care about that keeps a count of entries and exits and enables the __cxa_throw breakpoint if this is nonzero. However, this is hard to do reliably right now, because you have to do a lot of manual management of return breakpoints. I think this may get simpler when the "finish breakpoint" feature goes in: http://sourceware.org/ml/gdb-patches/2011-10/msg00394.html We're interested in hearing about real-life uses of exceptions and what better functionality gdb could provide. Freely file feature requests in gdb bugzilla; enhancing C++ development is a primary goal of ours these days. thanks, Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gdb: catching exceptions...
> "Michael" == Michael Stahl > 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 smoketest failed again today, i've distracted myself a bit Michael> with GDB Python scripting, the result of which is a command that can Michael> break when an exception is thrown, but only if a certain function Michael> (which is given as parameter) is on the stack. Nice. Michael> seems to work, but it is quite slow: finding the smoketest exception Michael> in SfxBaseModel::getTitle takes GDB 4 minutes of CPU time. Michael> now probably somebody will tell me that i'm too stupid to RTFM and Michael> there is a much simpler way to do this :) There isn't a simpler way right now. You could try to do it by having a breakpoint on the function you care about that keeps a count of entries and exits and enables the __cxa_throw breakpoint if this is nonzero. However, this is hard to do reliably right now, because you have to do a lot of manual management of return breakpoints. I think this may get simpler when the "finish breakpoint" feature goes in: http://sourceware.org/ml/gdb-patches/2011-10/msg00394.html We're interested in hearing about real-life uses of exceptions and what better functionality gdb could provide. Freely file feature requests in gdb bugzilla; enhancing C++ development is a primary goal of ours these days. thanks, Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gdb: catching exceptions...
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 and to find out what developers need from gdb. Michael> since my smoketest failed again today, i've distracted myself a bit Michael> with GDB Python scripting, the result of which is a command that can Michael> break when an exception is thrown, but only if a certain function Michael> (which is given as parameter) is on the stack. Nice. Michael> seems to work, but it is quite slow: finding the smoketest exception Michael> in SfxBaseModel::getTitle takes GDB 4 minutes of CPU time. Michael> now probably somebody will tell me that i'm too stupid to RTFM and Michael> there is a much simpler way to do this :) There isn't a simpler way right now. You could try to do it by having a breakpoint on the function you care about that keeps a count of entries and exits and enables the __cxa_throw breakpoint if this is nonzero. However, this is hard to do reliably right now, because you have to do a lot of manual management of return breakpoints. I think this may get simpler when the "finish breakpoint" feature goes in: http://sourceware.org/ml/gdb-patches/2011-10/msg00394.html We're interested in hearing about real-life uses of exceptions and what better functionality gdb could provide. Freely file feature requests in gdb bugzilla; enhancing C++ development is a primary goal of ours these days. thanks, Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Even more debugging info
> "Stephan" == Stephan Bergmann 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 size compared to -ggdb2? The short answer is yes, but there is a more complicated answer. First, one must consider the tradeoffs. I always use -g3 when building gdb, because gdb uses macros fairly heavily, and because I just don't care about the extra space. I prefer the convenience. YMMV of course, and I don't know enough about LibreOffice to offer an opinion. In a recent-enough GCC (I don't know if it made 4.6, but anyway I think it is in Fedora 16), there is a GNU extension to how macro information is represented. This extension greatly reduces the size of the macro information. If you really want to shrink debuginfo, use -gdwarf-4 and -fdebug-types-section. The former has been in GCC for a while, I don't remember when the latter was added. These options cause debuginfo for most big types to be shared across compilation units, a huge size win. This also makes gdb use less memory. The downside of this feature is that not all tools have been upgraded to understand it. gdb works fine, but the 7 dwarves, and systemtap, and I think valgrind, will barf. They will all come around eventually, though I am not sure when. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Even more debugging info
> "Lubos" == Lubos Lunak 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 boost::shared_ptr stuff in Lubos> one huge macro that'd avoid stepping through them (which I really Lubos> hate, as it's mostly pointless). CVS gdb has a 'skip' feature that can be used for this: (gdb) help skip Ignore a function while stepping. Usage: skip [FUNCTION NAME] If no function name is given, ignore the current function. [...] Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Even more debugging info
> "Lionel" == Lionel Elie Mamane 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. Lionel> And this GNU extension is enabled with "-ggdb3"? With "-gdwarf-4"? How Lionel> do I see whether it is used? If you use -g3 and do not use -gstrict-dwarf, then the new macro style is used. You can check for the new style using: readelf -WS ./some-file | grep debug_macro The old section name is called .debug_macinfo. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] concept for c++ based subsequenttests
> "Michael" == Michael Meeks 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 feature called "frame filters" that will let interpreters add additional data to backtraces. The idea is to be able to see the "raw" (implementation) stack frames and the "filtered" (interpreted) frames at the same time. This won't be in 7.4 but I hope it will be in the release after that. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: gdb backtrace burpage ...
> "Michael" == Michael Meeks 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 'framework::Frame' Michael> warning: RTTI symbol not found for class 'framework::Frame' Michael> But is there any way of suppressing that warning thrash for the Michael> case where it is not enabled ? There's no way to disable it. File a feature request in gdb bugzilla if you want that. I looked into this a little. The warning here is peculiar. Despite what it says, gdb is not actually looking for an RTTI symbol. Instead it is just looking for the debug info for the indicated type. I don't know a simple way to reproduce this problem, or I would dig into it a bit more. My guess is that it can only be reproduced in relatively odd situations, like where you have some subset of the debuginfo, but not quite all of it. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: gdb backtrace burpage ...
> "Christina" == Christina Roßmanith writes: Christina> You mean if I compile only a subset of modules with Christina> dbglevel>0? 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 remember, Christina> what I did immediately before "enabling" them...and I have Christina> the feeling that gdb -tui crashes quite often since then. Please report all crashes to gdb bugzilla. Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
