From Apache OpenOffice Wiki
Revision as of 10:07, 1 December 2005 by Frank Schoenheit (Talk | contribs)

Jump to: navigation, search

This section assumes use of gdb, from the console. There are also specific notes on Windows Debugging.

Building with debugging symbols

OO.o includes a way to add debugging code in per module, via the build debug=true command in each module. This also adds lots of runtime assertions, churning warnings etc. in addition to debug symbols - which can be useful. To do just a plain build with debug symbols though use build debug=true dbg_build_only=true

You can also configure OO.o with --enable-symbols to build with symbolic generation.

gdb invocation

If you debug with gdb, you may find that execution stops due to signals at inappropiate locations, especially if running against libgcj and need to debug ignoring its garbage-collection. Best invocation is...

gdb ./soffice.bin
(gdb) handle SIGPWR nostop noprint
(gdb) handle SIGXCPU nostop noprint
(gdb) handle SIG33 nostop noprint
(gdb) run -writer

replace -writer with -draw/-impress/-calc/... as appropiate.

Starting at the beginning

We start in 'main' with a sal wrapper, that calls vcl/source/app/svmain.cxx (SVMain). It invokes Main on pSVData->mpApp; but pSVData is an in-line local. To debug this use the pImplSVData global variable. eg:

     p pImplSVData->maAppData

This 'Main' method is typically: desktop/source/app/app.cxx (Main).

Examining strings

We have already seen that OO.o has it's own set of string classes, none of which gdb understands. You need to use: (gdb) print dbg_dump(sWhatEver) to print the contents of a UniString/ByteString/rtl::OUString/rtl::OString regardless of the type when debugging C++ code. See Caolan's write-up for details.

Getting the build order right

The build dependencies of the modules are clearly crucial to getting a clean build. When you type 'build' in a module, first build examines prj/build.list, eg.neon/prj/build.lst:

       xh      neon  :  soltools external expat NULL

this specifies that 'soltools', 'external' and 'expat' have to be satisfactorily built and delivered before neon can be built. Occasionally these rules get broken, and people don't notice for a while.

It crashes, but only in gdb

What fun — you symlinked desktop/ to soffice.bin in your install tree didn't you. That works fine if you just run it, but it seems gdb unpacks the symlink and passes a fully qualified path as argv[0], which defeats the hunting for the binary in the path, so it assigns the program base path as /opt/OpenOffice/OOO_STABLE_1/desktop/ and starts looking for (eg. applicat.rdb) in there. Of course when it fails to find any setup information, it silently crashes somewhere else yards away from the original problem.

It crashes, but doesn't crash

For various reasons signal handlers are trapped and life can get rather confusing; thus it's best for builders to apply something like this:

--- sal/osl/unx/signal.c
+++ sal/osl/unx/signal.c
@@ -188,6 +188,8 @@ static sal_Bool InitSignal()
             bSetILLHandler = sal_True;
+       bSetSEGVHandler = bSetWINCHHandler = bSetILLHandler = bDoHardKill = sal_False;
        SignalListMutex = osl_createMutex();
        act.sa_handler = SignalHandlerFunction;

I can't find the code from the trace

Some methods, are described as having a special linkage, such that they can be used in callbacks; these typically have a prefix: 'LinkStub', so search for the latter part of the identifier in a freetext search. eg.

      IMPL_LINK( Window, ImplHandlePaintHdl, void*, EMPTYARG )

builds the 'LinkStubImplHandlePaintHdl' method.

How can I re-build just the files I see in the trace

Often when you run gdb on a build without debugging symbols, you get an unhelpful gdb trace, but yet you can't afford the time/space to recompile all of OO.o with debugging symbols. Thus we have created a small perl helper, which will hunt for & touch files containing the symbols from your trace. This sub-set can then be re-built with debugging enabled for a better trace next time around:

    gdb ./soffice.bin
#0  0x40b4e0a1 in kill () from /lib/
#1  0x409acfe6 in raise () from /lib/
#2  0x447bcdbd in SfxMedium::DownLoad(Link const&) () from ./
#3  0x447be151 in SfxMedium::SfxMedium(String const&, unsigned short, unsigned char, SfxFilter const*, SfxItemSet*) ()
   from ./
#4  0x448339d3 in getCppuType(com::sun::star::uno::Reference<com::sun::star::document::XImporter> const*) () from ./
    cd base/OOO_STABLE_1/sfx2
    ootouch SfxMedium
    build debug=true

Thus, all files referencing / implementing anything with SfxMedium will be touched, and hence rebuilt with debugging symbols.

How can I re-build all the files in one source directory

If you want to recompile the code in just your current directory, you can use the killobj dmake target to remove the object files:

    dmake killobj

It always crashes in sal_XErrorHdl

You are a victim of asynchronous X error reporting; export SAL_SYNCHRONIZE=1 will make all the X traffic synchronous, and report the error by the method that caused it, it'll also make OO.o far slower, and the timing different.

It silently fails to load my word file

Caolan suggests: put breakpoints in ww8par.cxx top and tail of SwWW8ImplReader::LoadDoc, and confirm that the document gets as far as the import filter.

A handy human place to put a breakpoint is in SwWW8ImplReader::ReadPlainChars, you can see chunks of text as they are read in. Alternatively SwWW8ImplReader::AppendTxtNode as each paragraph is inserted.

How do I use the debug console ?

So OO.o contains some hefty debugging infrastructure; pictured [here]

Enabling it is pretty easy - what you need is a so-called non-product build.

By default, an build is a Product Build, i.e. ready for release after completion. If you specifiy the --enable-dbgutil switch during configure, then your environment will be prepared for a Non-Product Build - with lots of additional diagnostic tools.

After using this switch, build and package as usual. Now - just run OO.o, and when it's in full-flow, press <Alt>-<Shift>-<Control> 'D' in that order; this should popup a debugging options window. The debugging options are subsequently saved to the .dbgsv.init file for the next run; you can control the location of that with: export DBGSV_INIT=$(HOME)/.dbgsv.init eg. it is (unfortunately) a binary file.

Note that libraries from product and non-product builds are usually incompatible, so don't mix them in the same installation.

For available tools in non-product builds, have a look at the various DBG_foo macros in tools/debug.hxx, or, if you already are knowledgeable about this, let others participate by writing your knowledge down here.

Excel Interop debugging

This is fairly easy; edit sc/source/filter/inc/biffdump.hxx, define EXC_INCL_DUMPER to 1, and re-build 'sc'. Also, copy sc/source/filter/excel/biffrecdumper.ini to ~. Then run soffice.bin foo.xls and you should get a foo.txt with the debug data in it.

The trace shows a crash in 'poll'

OO.o is a fairly threaded program, you're prolly just looking at the wrong thread: there are not likely to be bugs in poll. Use thread apply all backtrace to get a backtrace of all threads - this will most likely fail. When it does do: thread 1 then bt - most crashers occur in the 'main' thread.

What does this trace mean ?

There are several typical stack-traces that come up again and again, one would be:

#15 0x4164a501 in raise () from /lib/tls/
#16 0x4164bcd9 in abort () from /lib/tls/
#17 0x415fb5a5 in std::set_unexpected ()
   from /home/mnagashree/m72install/program/
#18 0x415fb5e2 in std::terminate ()
   from /home/mnagashree/m72install/program/
#19 0x415fb69c in __cxa_rethrow ()

This section of trace means (essentially) that an exception was thrown - but there was no-one trying to catch it. Often this means there was a missing 'try {} catch()' clause in one of the calling frames.

A great way to debug exceptions is to add a breakpoint in catch/throw, do this with catch throw or catch catch in gdb.

Personal tools