Download it now!
Bug 63339 - Libreoffice crashes by itself while typing/pasting
Summary: Libreoffice crashes by itself while typing/pasting
Status: RESOLVED DUPLICATE of bug 62167
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.1.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-09 21:15 UTC by Wirawan Purwanto
Modified: 2013-04-11 17:40 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
JRE error log (?) (115.46 KB, text/plain)
2013-04-09 21:15 UTC, Wirawan Purwanto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wirawan Purwanto 2013-04-09 21:15:06 UTC
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
Comment 1 Julien Nabet 2013-04-10 21:30:50 UTC
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 ||
?
Comment 2 Michael Meeks 2013-04-11 11:03:37 UTC
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 ?
Comment 3 Julien Nabet 2013-04-11 11:09:57 UTC
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?
Comment 4 Michael Meeks 2013-04-11 12:13:47 UTC
> 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 :-)
Comment 5 Michael Meeks 2013-04-11 12:18:07 UTC
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 :-)
Comment 6 Michael Meeks 2013-04-11 12:19:06 UTC
found it :-)

*** This bug has been marked as a duplicate of bug 62167 ***
Comment 7 Julien Nabet 2013-04-11 17:17:17 UTC
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.
Comment 8 Michael Meeks 2013-04-11 17:40:13 UTC
hey - no problem; thanks for caring & digging through fixing bugs - that is just great work ! :-)