Created attachment 77696 [details] JRE error log (?) Don't remember anymore what exactly I did that caused the crash. Here's the error message in terminal console: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fa0da9e37cb, pid=6149, tid=140329497503552 # # JRE version: 6.0_18-b18 # Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 ) # Derivative: IcedTea6 1.8.13 # Distribution: Debian GNU/Linux 6.0.4 (squeeze), package 6b18-1.8.13-0+squeeze2 # Problematic frame: # C [libeditenglo.so+0x2017cb] _ZNK15LatinLookupTree21suggestAutoCompletionEv+0x5b # # An error report file with more information is saved as: # /data1/wirawan/distrib/office/LibreOffice/hs_err_pid6149.log # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # [error occurred during error reporting , id 0xb] [1] Exit 134 /opt/libreoffice4.0/program/soffice (wd: /l/distrib/office/LibreOffice) OS: Debian Linux 6.0.6 (despite what it said above) (x86_64) Kernel: Linux 3.2.0-0.bpo.4-amd64 Wirawan
Michael: by taking a look to http://opengrok.libreoffice.org/xref/core/editeng/source/lookuptree/LatinLookupTree.cxx#115, 120 Node* pWalker = m_pCurrent; 121 122 int distance = 0, nTargetProbability = 0; 123 OUString sSuggestion; 124 125 while ( pWalker->m_pSuggest && ( distance < 2 || 126 // Make sure the suggestion is at least 2 chars long. 127 nTargetProbability == pWalker->m_nHighestProbaInSubtree ) ) 128 { 129 if ( distance < 2 ) 130 nTargetProbability = pWalker->m_nHighestProbaInSubtree; 131 132 // follow the tree along the suggested route 133 pWalker = pWalker->m_pSuggest; 134 ++distance; 135 sSuggestion += OUString(pWalker->m_cKey); 136 } what about adding a check on pWalker line 125 to have: while ( pWalker && pWalker->m_pSuggest && ( distance < 2 || ?
The code in master has: 117 if ( !m_pCurrent ) 118 return OUString(); 119 120 Node* pWalker = m_pCurrent; So we check the initial pWalker is not NULL, and AFAICS bail out if pWalker->m_pSuggest is NULL before we assign that to pWalker. Is that perhaps missing in the -4-0 branch or something ? or is that a new change ?
Michael: you're right for the first loop but then, line 133: pWalker = pWalker->m_pSuggest; but could pWalker->m_pSuggest returns NULL and so pWalker could be NULL after first loop?
> Michael: you're right for the first loop but then, line 133: Great :-) > pWalker = pWalker->m_pSuggest; > but could pWalker->m_pSuggest returns NULL Sure but we already checked it is not NULL in the while: 125 while ( pWalker->m_pSuggest && .. So it has to be valid at that point I think (?) - of course, possibly I'm mis-reading, this is C++ after all something evil could be hidden behind the types :-)
My suspicion would be (since the sw/ code calling this is remarkably simple) that we are simply not correctly updating m_pCurrent as/when some change is made to the tree somehow. Annoying really - I think we've seen another of these around the place - I think this is a duplicate, it would be fantastically useful to be able to repeat this of course :-)
found it :-) *** This bug has been marked as a duplicate of bug 62167 ***
After having prepared a quite long answer to your last comment about nullity or not of pWalker, I read again the code and finally understood. So you were completely right Michael, as usual! :-) Sorry for the noise and thank you for your patience.
hey - no problem; thanks for caring & digging through fixing bugs - that is just great work ! :-)