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 ...
Hi Cor, now we'd need a backtrace :-) http://wiki.documentfoundation.org/BugReport#How_to_get_backtrace_.28on_Linux.29 Thank you a lot!
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 ?? () (gdb)
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.
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. Alex
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?
@ Cor No problems with keyboard arrows scroll.
@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) ? Alex
Still crashing in linux RC4: $ cat /opt/libreoffice/program/versionrc [Version] AllLanguages=en-US buildid=330m19(Build:6) ExtensionUpdateURL=http://updateexte.libreoffice.org/ExtensionUpdateService/check.Update OOOBaseVersion=3.3 ProductBuildid=6 ProductMajor=330 ProductMinor=19 ProductSource=OOO330 UpdateID=LibreOffice_3_en-US UpdateURL= UpdateUserAgent=<PRODUCT> (${buildid}; ${_OS}; ${_ARCH}; BundledLanguages=${AllLanguages}) Does not crash in: Linux: $ cat /opt/ooo-dev3/program/versionrc [Version] AllLanguages=en-US buildid=300m98(Build:9568) ... OOOBaseVersion=3.4 ProductBuildid=9568 ProductMajor=300 ProductMinor=98 ProductSource=DEV300 UpdateID=OOo-dev_3_en-US $ cat /opt/openoffice.org3/program/versionrc [Version] AllLanguages=en-US buildid=320m18(Build:9502) ... OOOBaseVersion=3.2 ProductBuildid=9502 ProductMajor=320 ProductMinor=18 ProductSource=OOO320 UpdateID=OpenOffice.org_3_en-US Windows (XP SP3) LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 Tested by: File|New|Database| 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.
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
Created attachment 42364 [details] gdb back trace
Created attachment 42392 [details] valgind log of crash
Created attachment 42393 [details] patch to get the same debug printout shown in the valgrind log
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
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 :-(
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.
triaged, reproduced, fix potentially available
(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 )
somebody has to own it I guess :-) I agree with Caolans patch so I will commit this to master and the libreoffice3.3 branch
I saw those commits go in earlier today, so lets mark this as fixed.