*** 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

Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team

This NEEDINFO message was generated on: 2015-07-18

Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO
Message generated on: 2015-09-03