Bug 83013

Summary: EDITING: segfault after multiple searches
Product: LibreOffice Reporter: Knut Esztermann <knut>
Component: DatabaseAssignee: Not Assigned <libreoffice-bugs>
Status: NEEDINFO --- QA Contact:
Severity: normal    
Priority: medium CC: iplaw67, knut, lionel, serval2412, zpm008
Version: 4.3.0.4 release   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: libreoffice --backtrace
JRE error file after crash

Description Knut Esztermann 2014-08-24 13:04:29 UTC
Created attachment 105197 [details]
libreoffice --backtrace

When performing searches (local) in a mysql database, libreoffice crashes sometimes. I am not able to define the circumstances leading to the crash.

Backtrace attached.

Steps to reproduce:
1. Open up a database form (showing one of several records)
2. Click on the goggles
3. Enter a search text and hit Enter

Results:
About one in one to ten cases, it segfaults

LibreOffice
Version: 4.3.0.4
Build ID: 430m0(Build:4)

on 3.14-2-rt-amd64 #1 SMP PREEMPT RT Debian 3.14.15-2 (2014-08-09) x86_64 GNU/Linux
Comment 1 Caolán McNamara 2014-08-27 19:43:59 UTC
*** Bug 83051 has been marked as a duplicate of this bug. ***
Comment 2 Alex Thurgood 2014-09-09 13:36:16 UTC
just tried 30 iterations of searching for "cust" in the field Lastname of the form from the odb posted in bug 83051, no crash
Comment 3 Knut Esztermann 2014-09-09 19:06:50 UTC
Ok, I did some more testing and tried to reproduce with the Subscribers Database.

Here is who I got a crash:

1. open form
2. set sorting to 'last name', then 'first name'
3. create a new record, just enter subscription date, name and license id
4. search for 'ly' in first name

Then it crashes. I'm not entirely sure if this is the same bug since I got a java error file (hs_err_pid21063.log, attached) this time. I was not able to make a --backtrace, since then a crash happend already when opening the form.

I did this on Version: 4.3.1.2, Build ID: 430m0(Build:2)
Comment 4 Knut Esztermann 2014-09-09 19:10:29 UTC
Created attachment 106000 [details]
JRE error file after crash
Comment 5 Alex Thurgood 2014-10-21 10:44:03 UTC
Well, it seems from your jvm log that there is a problem with parallel garbage collection from different threads involving hsqldb, but I don't understand why if you're connecting to a mysql db ?

Compilation events (10 events):
Event: 27.486 Thread 0x00007f8ff9740000 nmethod 124 0x00007f8ff50aab10 code [0x00007f8ff50aac60, 0x00007f8ff50aad28]
Event: 27.486 Thread 0x00007f8ff9740000  125             java.lang.Thread::<init> (69 bytes)
Event: 27.491 Thread 0x00007f8ff9743000 nmethod 119 0x00007f8ff50b1e90 code [0x00007f8ff50b2060, 0x00007f8ff50b2ae8]
Event: 27.497 Thread 0x00007f8ff9740000 nmethod 125 0x00007f8ff50b3290 code [0x00007f8ff50b3460, 0x00007f8ff50b3da0]
Event: 51.599 Thread 0x00007f8ff9740000  127             org.hsqldb.lib.HashMappedList::checkRange (21 bytes)
Event: 51.599 Thread 0x00007f8ff9743000  126             org.hsqldb.lib.HashMappedList::get (12 bytes)
Event: 51.600 Thread 0x00007f8ff9740000 nmethod 127 0x00007f8ff50ada10 code [0x00007f8ff50adb60, 0x00007f8ff50adbf8]
Event: 51.601 Thread 0x00007f8ff9743000 nmethod 126 0x00007f8ff50aee50 code [0x00007f8ff50aefa0, 0x00007f8ff50af078]
Event: 51.634 Thread 0x00007f8ff9740000  128             org.hsqldb.Table::getColumn (12 bytes)
Event: 51.636 Thread 0x00007f8ff9740000 nmethod 128 0x00007f8ff50aea10 code [0x00007f8ff50aeb60, 0x00007f8ff50aec78]


I did notice this too :

R14=0x00007f900c507830: <offset 0x97830> in /usr/lib/libreoffice/program/../program/libdbalo.so at 0x00007f900c470000
R15=0x00007fff8ab3d600 is an unknown value


Stack: [0x00007fff8aa42000,0x00007fff8ab42000],  sp=0x00007fff8ab3d520,  free space=1005k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libdbalo.so+0x97971]  void std::vector<int, std::allocator<int> >::_M_emplace_back_aux<int const&>(int const&)+0x118e1

However, I am unsure ofthe significance of any of this
Comment 6 Alex Thurgood 2014-10-21 10:54:53 UTC
And this in your gdb output


0x00007fffc3bc18f1 in operator[] (this=<optimized out>, __n=<optimized out>) at /usr/include/c++/4.9/bits/stl_vector.h:780
780	      { return *(this->_M_impl._M_start + __n); }

so something not quite right in stl_vector ?
Comment 7 Joel Madero 2014-10-23 01:32:27 UTC
Lionel - thoughts on this one?
Comment 8 Lionel Elie Mamane 2014-10-23 07:05:29 UTC
(In reply to Alex Thurgood from comment #6)

> 0x00007fffc3bc18f1 in operator[] (this=<optimized out>, __n=<optimized out>)
> at /usr/include/c++/4.9/bits/stl_vector.h:780
> 780	      { return *(this->_M_impl._M_start + __n); }
> 
> so something not quite right in stl_vector ?

This looks like an out-of-bound access in a std::vector, like e.g. accessing the 5th element when there are only 3 elements.
Comment 9 Lionel Elie Mamane 2014-10-24 21:14:57 UTC
Could not reproduce in my (somewhat old / 173e0172092fa87606a80a7b0d6b89323c7166b5 of 26 sep 2014) master (4.4.0.alpha) tree.
Comment 10 Julien Nabet 2014-12-05 22:12:53 UTC
Could you upgrade to 4.3.4?
Also, do you reproduce this with an embedded hsqldb file?

Did you install any LO specific extension?

Finally, it could be useful you rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile#GNU.2FLinux) and give it a new try.
Comment 11 Alex Thurgood 2015-01-03 17:40:15 UTC
Adding self to CC if not already on

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.