Bug 32561 - Crash when moving through database types (File > New > Database, open existing)
Summary: Crash when moving through database types (File > New > Database, open existing)
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
3.3.0 RC1
Hardware: x86 (IA32) Linux (All)
: medium critical
Assignee: Noel Power
Depends on:
Reported: 2010-12-21 12:25 UTC by Cor Nouws
Modified: 2013-11-14 22:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

gdb back trace (11.59 KB, text/plain)
2011-01-24 03:52 UTC, Noel Power
valgind log of crash (192.33 KB, text/x-log)
2011-01-24 11:47 UTC, Noel Power
patch to get the same debug printout shown in the valgrind log (3.13 KB, patch)
2011-01-24 11:48 UTC, Noel Power
quick fix (1.40 KB, patch)
2011-01-25 08:05 UTC, Caolán McNamara

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2010-12-21 12:25:21 UTC
To reproduce
- File > New > Database
- Choose Open existing
- open list with mouse, arrow down halfway, bit up /down ..
 > crash

Sometimes crash is with selecting LDAP, sometimes with KDE adressbook, sometimes with ...
Comment 1 Jan Holesovsky 2010-12-22 02:03:04 UTC
Hi Cor, now we'd need a backtrace :-)


Thank you a lot!
Comment 2 Cor Nouws 2010-12-22 02:46:37 UTC
Hi Kendy,

this freezes both LibO and the terminal (and part of the Ubuntu GUI). 
Could not give any command (incl Ctrl-C) in the terminal.
Had to kill the gdb ./soffice.bin in another terminal.

Terminal output:

~/LibO330rc1/libreoffice/program$ gdb ./soffice.bin 2>&1 | tee /tmp/gdb.log
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.

Reading symbols from /home/cono/LibO330rc1/libreoffice/program/soffice.bin...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/cono/LibO330rc1/libreoffice/program/soffice.bin 
[Thread debugging using libthread_db enabled]
[New Thread 0xb4efbb70 (LWP 2348)]
[New Thread 0xb2a66b70 (LWP 2350)]
[New Thread 0xb2265b70 (LWP 2351)]
[New Thread 0xb16a3b70 (LWP 2352)]
[New Thread 0xb09b4b70 (LWP 2353)]
[New Thread 0xafe01b70 (LWP 2354)]
[Thread 0xb2a66b70 (LWP 2350) exited]
[New Thread 0xb2a66b70 (LWP 2359)]
[Thread 0xb2a66b70 (LWP 2359) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00000018 in ?? ()
Comment 3 Zoltán Reizinger 2010-12-30 06:47:25 UTC
On win7 with LibO 3.3RC2 opens without problem, in File>Open>Database all option.

On opensuse 11.3 LibO 3.3RC2, when I select from available files on dropdown list, open selected file.
When I use KDE4 file selector "Open..." select same odb file with built-in hsqldb, and click OK, I get error message: "Please choose 'Choose existing database' to connect to an existing database instead."
When click OK brings selection down to "Connect to an existing database" option.
Comment 4 Alex Thurgood 2011-01-06 09:06:34 UTC
Hi all,

Can not reproduce on Mac OSX 10.6.5, LibO RC2. I can scroll up or down the possible choices without a problem, but then on Mac there is a more limited choice of DB sources, for example, there is no KDE address book, no LDAP, no Evolution address book.

Comment 5 Cor Nouws 2011-01-07 06:35:07 UTC
Still reproducable in rc3.
Essential: do not scroll through the file types with the mouse, but with the arrow-keys.

@Zoltán: did you try it that way?

@Alex: might well be that your comment is spot on..

@kendy: any tip on how to succesfully retrieve a backtrace? Different start options or so?
Comment 6 Zoltán Reizinger 2011-01-07 07:25:44 UTC
@ Cor 
No problems with keyboard arrows scroll.
Comment 7 Alex Thurgood 2011-01-07 09:21:37 UTC
@Cor : I tried it both ways before commenting, both mouse and arrow keys, just to be sure.

Hmm, I was wondering whether this isn't linked to other apparent X related crashes on Linux that have been filed as bugs recently (the Powerpoint ones in particular) ?

Comment 8 NoOp 2011-01-22 15:26:20 UTC
Still crashing in linux RC4:
$ cat /opt/libreoffice/program/versionrc
UpdateUserAgent=<PRODUCT> (${buildid}; ${_OS}; ${_ARCH}; BundledLanguages=${AllLanguages})

Does not crash in:

$ cat /opt/ooo-dev3/program/versionrc

$ cat /opt/openoffice.org3/program/versionrc

Windows (XP SP3)
LibreOffice 3.3.0
OOO330m19 (Build:6)
tag libreoffice-

Tested by:

  Connect to an existing database
use mouse click, mouse wheel or down arrow to select 'LDAP Address Book'.
If the mouse is used to select any other option, LORC4 does not crash.
Comment 9 Noel Power 2011-01-24 03:51:27 UTC
this is bad, trace to be attached, think we need some debug build to drill down a bit further to where it is going wrong
Comment 10 Noel Power 2011-01-24 03:52:28 UTC
Created attachment 42364 [details]
gdb back trace
Comment 11 Noel Power 2011-01-24 11:47:08 UTC
Created attachment 42392 [details]
valgind log of crash
Comment 12 Noel Power 2011-01-24 11:48:28 UTC
Created attachment 42393 [details]
patch to get the same debug printout shown in the valgrind log
Comment 13 Noel Power 2011-01-24 12:03:34 UTC
without my crummy debug statements the location of the crash in comphelper/source/property/opropertybag.cxx is shown below

 510  // there's a property requested which we do not know
 511  if ( m_bAutoAddProperties )
 512  {
 513      // add the property
 514      sal_Int16 nAttributes = PropertyAttribute::BOUND | PropertyAttribute::REMOVEABLE | PropertyAttribute::MAYBEDEFAULT;
 515      addProperty( *pName, nAttributes, pProperty->Value );
 516      // rPropInfo is invalid, refetch
 517      rPropInfo = getInfoHelper();
*518      *pHandle = rPropInfo.getHandleByName( *pName );
 519      continue;
 520   }

The valgrind log seems to indicate that the rPropInfo returned from getInfoHelper has been deleted e.g.

==8524== Invalid read of size 8
==8524==    at 0x6CD2BF0: comphelper::OPropertyBag::impl_setPropertyValues_throw(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (opropertybag.cxx:528)
==8524==    by 0x6CD30D0: comphelper::OPropertyBag::setPropertyValues(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (opropertybag.cxx:565)
==8524==    by 0x20435004: dbaccess::(anonymous namespace)::lcl_setPropertyValues_resetOrRemoveOther(com::sun::star::uno::Reference<com::sun::star::beans::XPropertyAccess> const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (datasource.cxx:931)


==8524==  Address 0x17dc66f0 is 0 bytes inside a block of size 32 free'd
==8524==    at 0x4C25F7B: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8524==    by 0x6CD4B0F: std::auto_ptr<cppu::OPropertyArrayHelper>::reset(cppu::OPropertyArrayHelper*) (auto_ptr.h:242)
==8524==    by 0x6CD2320: comphelper::OPropertyBag::addProperty(rtl::OUString const&, short, com::sun::star::uno::Any const&) (opropertybag.cxx:368) 

but this ( afaics ) doesn't tally with the debug output I get :-/ which seems to indicate we never access 0x17dc66f0 at ( opropertybag.cxx:528 ) I have to admit I don't get it :-/// something strange is happening here or I am missing something obvious
Comment 14 Noel Power 2011-01-25 06:55:27 UTC
after even more manic osl_trace goodness I still don't see the problem that valgrind indicates so I begin to suspect some deeper system allocation type problem. On master it seems if I unset G_SLICE I no longer see the core and valgrind remains happy never complaining as I zip up and down the database list using the keys :-/

rc4 libreoffice on the other hand demonstrates the bug, I suppose we built with FORCE_SYSALLOC then :-(
Comment 15 Caolán McNamara 2011-01-25 08:05:00 UTC
Created attachment 42468 [details]
quick fix

The original code suffers from a brain fart, maybe because of reference/pointer confusion or uno reference vs c++ references

read it like so and the problem becomes apparant

::cppu::IPropertyArrayHelper* pPropInfo = getInfoHelper();
// rPropInfo is invalid, refetch (i.e. something like pPropInfo = NULL has happened.
*pPropInfo = getInfoHelper(); //what the fuck
*pHandle = pPropInfo->getHandleByName( *pName );

attached patch is safe option, get an up to date c++ reference at the start of each loop and throw it away and refetch every time. Otherwise need to get the underlying pointer instead and cache that and refetch on invalid.
Comment 16 Caolán McNamara 2011-01-25 08:09:12 UTC
triaged, reproduced, fix potentially available
Comment 17 Noel Power 2011-01-26 01:17:20 UTC
(In reply to comment #15)
> The original code suffers from a brain fart, maybe because of reference/pointer
> confusion or uno reference vs c++ references

yup and I suffered from the same reference confusion too when looking at this,  well ( 'nough said )
Comment 18 Noel Power 2011-01-26 01:50:08 UTC
somebody has to own it I guess :-)

I agree with Caolans patch so I will commit this to master and the libreoffice3.3 branch
Comment 19 Caolán McNamara 2011-01-26 13:27:00 UTC
I saw those commits go in earlier today, so lets mark this as fixed.