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
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 inst
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_pr
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
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 o
>>>>> "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. H
> "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.
'checkSiz
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
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>
> "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> confuse
> "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 all
> "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
> "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 th
> "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 --
wit
> "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
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.
> "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,
> "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 "h
> "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 i
> "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 po
>>>>> "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&
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
ma
>>>>> "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
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
> "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 dist
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 a
> "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 com
> "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 boo
> "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.
Lione
> "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 "f
> "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::Fr
> "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,
Chr
33 matches
Mail list logo
