Bug 83013

*** Bug 83051 has been marked as a duplicate of this bug. ***

just tried 30 iterations of searching for "cust" in the field Lastname of the form from the odb posted in bug 83051, no crash

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)

Created attachment 106000 [details]
JRE error file after crash

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

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 ?

Lionel - thoughts on this one?

(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.

Could not reproduce in my (somewhat old / 173e0172092fa87606a80a7b0d6b89323c7166b5 of 26 sep 2014) master (4.4.0.alpha) tree.

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.

Adding self to CC if not already on