Bug Hunting Session
Bug 56460 - CRASH when closing specific .odg files
Summary: CRASH when closing specific .odg files
Status: RESOLVED DUPLICATE of bug 57901
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: Other All
: high major
Assignee: Not Assigned
URL:
Whiteboard: BSA target:3.7.0
Keywords: regression
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2012-10-27 12:44 UTC by Julien Nabet
Modified: 2012-12-05 19:10 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
backtrace with symbols (18.99 KB, text/plain)
2012-10-27 12:44 UTC, Julien Nabet
Details
valgrind logs (44.31 KB, application/x-bzip)
2012-10-31 23:07 UTC, Julien Nabet
Details
Additional Sample Document (25.53 KB, application/vnd.oasis.opendocument.graphics)
2012-11-01 06:25 UTC, Rainer Bielefeld Retired
Details
refactor with side-effect of not crashing (6.33 KB, patch)
2012-11-07 21:30 UTC, Caolán McNamara
Details
bt on master (5.37 KB, text/plain)
2012-11-18 20:41 UTC, Julien Nabet
Details
autogen.lastrun (650 bytes, text/plain)
2012-11-19 07:26 UTC, Julien Nabet
Details
bt with symbols + console logs (19.40 KB, text/plain)
2012-11-20 18:35 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2012-10-27 12:44:28 UTC
Created attachment 69148 [details]
backtrace with symbols

Problem description:
On pc Debian x86-64 wiht master sources updated today (7b633213c0d814d0fd485a6070291944e9890cee), when closing sample.odg file from fdo#42939 (https://bugs.freedesktop.org/attachment.cgi?id=65473&action=edit), I got a crash.

Steps to reproduce:
1. Retrieve 7z file from https://bugs.freedesktop.org/attachment.cgi?id=65473&action=edit
2. "un7z"
3. open sample.odg
4. close LO

Current behavior:
Crash
Expected behavior:
No crash

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.9) Gecko/20100101 Firefox/10.0.9 Iceweasel/10.0.9
Comment 1 Julien Nabet 2012-10-31 23:07:40 UTC
Created attachment 69374 [details]
valgrind logs

I reproduced the problem and retrieved valgrind trace
Comment 2 Julien Nabet 2012-10-31 23:16:31 UTC
Rainer/Roman: would you have some time to try to reproduce this?
I'd like to know if it concerns only Linux (my config only?) or not?
Comment 3 Rainer Bielefeld Retired 2012-11-01 06:14:00 UTC
More or less [Reproducible with parallel installation of Master "LOdev  3.7.0.0.alpha0+  -  ENGLISH UI / German Locale  [Build ID: af8098)]"  {tinderbox: @16, pull time 2012-10-31 23:08:18} on German WIN7 Home Premium (64bit) with separate User Profile for Master Branch.

I open a new WRITER document  from LibO Start Center, open "sample.odg" from  Attachment 65473 [details] using LibO File Open dialog, close without having edited using menu 'File -> Exit' or Window top right Close-X button. Sometimes no crash, sometimes crash when close, sometimes crash when reopen form 'Recent Documents'

The Crash is not limited to that document, I will attach another one what also shows the crash. Not all my Drawings crash, but I vound several additional ones showing the CRASH problem.

@Radek:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf
Comment 4 Rainer Bielefeld Retired 2012-11-01 06:25:45 UTC
Created attachment 69380 [details]
Additional Sample Document

Currently I do no know what in the Drawings causes the crash.
Comment 5 Roman Eisele 2012-11-02 09:23:56 UTC
(In reply to comment #2)
> Rainer/Roman: would you have some time to try to reproduce this?
> I'd like to know if it concerns only Linux (my config only?) or not?

Sorry for the delay! I was mostly away this week.
Well, Rainer has already confirmed this bug (thanks!). So only for the record:

NOT reproducible with Rainer’s sample file (from comment #4) and
LOdev 3.7.0.0.alpha0+ (Build ID: ce2690; pull time: 2012-10-30 00:06:37)
on Mac OS X 10.6.8 (Intel). No crash occurs when closing the sample document and/or the complete application.

-> Bug seems limited to Windows and Linux.
Comment 6 Caolán McNamara 2012-11-07 21:11:53 UTC
caolanm->mmeeks: reverting 1d16f59023b1b19d01ca69b8c9735be6d3baf5d9 makes this not crash again. Some twisted who-owns-what loop me guesses. Throwing a weak reference at it doesn't help.
Comment 7 Caolán McNamara 2012-11-07 21:30:02 UTC
Created attachment 69671 [details]
refactor with side-effect of not crashing

If we code in route-one mode the result doesn't crash for me on exit of the .odg and I see that the SdrObjCustomShape dtors are getting called on close of the .odg suggesting that on the face of it anyway that its sane.
Comment 8 Michael Meeks 2012-11-08 09:56:07 UTC
Wow - thanks Caolan ! :-)

Thorsten - your optimism about the lifecycle of those peers appears to have been misplaced ;-) What do you think of Caolan's approach ? - it looks very sensible to me I guess.
Comment 9 Thorsten Behrens (CIB) 2012-11-08 10:26:48 UTC
(In reply to comment #8)
> Thorsten - your optimism about the lifecycle of those peers appears to have
> been misplaced
>
That sucks, and will bite someone using that from the outside then -

> What do you think of Caolan's approach ? - it looks very
> sensible to me I guess.
>
Yep, quite!
Comment 10 Michael Meeks 2012-11-08 12:03:47 UTC
Pushed; thanks ! :-)
Comment 11 Not Assigned 2012-11-08 12:06:16 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=67f899e1d2db0dccde4b9587a52b7157fe1fb0be

Resolves: fdo#56460 don't crash on close of files with custom shapes



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 12 luksiw 2012-11-18 12:59:46 UTC
Worls fine without crashing for Version 4.0.0.0.alpha0+ (Build ID: 04f2f0).
Comment 13 Julien Nabet 2012-11-18 20:41:08 UTC
Created attachment 70237 [details]
bt on master

On pc Debian x86-64 with master sources updated 3 days ago, I still reproduce this bug :( I attached a new bt but at first glance, seemed quite similar.

Caolán: an idea?
Comment 14 Julien Nabet 2012-11-18 20:41:41 UTC
Following my last comment, I reopen this tracker badfully
Comment 15 Rainer Bielefeld Retired 2012-11-19 05:25:03 UTC
No longger reproducible with parallel installation of Master "LOdev  4.0.0.0.alpha0+   -  ENGLISH UI / German Locale  [Build ID: a2b3ee)]"  {tinderbox: @6, pull time 2012-11-13 06:07:28} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch

So it seems the fix was for a crash problem different from Julien's?
Comment 16 Julien Nabet 2012-11-19 07:26:24 UTC
Created attachment 70242 [details]
autogen.lastrun

I attached my autogen.lastrun.

Here are some more info about my config
3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
gcc (Debian 4.7.2-4) 4.7.2
GNU Make 3.81
ldd (Debian EGLIBC 2.13-35) 2.13
Comment 17 Jean-Baptiste Faure 2012-11-19 07:52:13 UTC
No crash for me with Version 4.0.0.0.alpha0+ (Build ID: 1444a0) (updated 2012-11-18)
Ubuntu 12.04 x86_64
My autogen.lastrun :
--without-junit
--enable-ext-pdfimport
--enable-ext-presenter-console
--enable-ext-presenter-minimizer
--with-lang=en-US fr
--enable-binfilter
--enable-graphite
--with-system-cairo
--without-doxygen
--enable-ext-nlpsolver
--with-system-openssl
--disable-neon
--with-system-openldap
--with-parallelism=2

Julien: did you made a clean build ? Sometimes it helps :-)

Best regards. JBF
Comment 18 Julien Nabet 2012-11-19 10:18:56 UTC
JB: I runned it a "make clean". This morning, I retrieved last master sources and launched a "make clean && make && make dev-install", I think I'll leave a post here tonight.
Comment 19 Julien Nabet 2012-11-20 07:21:24 UTC
Michael: Do you think I should try to build LO with JB's autogen.lastrun or to get another Valgrind trace to provide helpful info?
Comment 20 Michael Meeks 2012-11-20 10:54:36 UTC
> Michael: Do you think I should try to build LO with JB's autogen.lastrun
> or to get another Valgrind trace to provide helpful info?

Given that your trace looks identical to the issue that Caolan fixed, and others can't reproduce it with tinderbox built binaries - I strongly suspect some build problem here :-)

It would help to know which git hash you're building from too I guess (?).

Thanks !
Comment 21 Julien Nabet 2012-11-20 15:27:42 UTC
Michael: master sources for the test have been retrieved until http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd91019804398c0643951eb291a45d3931968ae3. It still crashes :(
Comment 22 Julien Nabet 2012-11-20 18:35:44 UTC
Created attachment 70328 [details]
bt with symbols + console logs

I attached last bt + console logs I hadn't notice (or perhaps it wasn't there last time)
Comment 23 Julien Nabet 2012-11-20 18:38:00 UTC
Logs are the same but not the same lines:
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:517: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:379: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:517: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:517: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:379: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:517: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:517: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:379: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:517: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:517: fuer Image, dort gibt es derzeit keine Statics - Bug
warn:svl.items:32455:1:/home/julien/compile-libreoffice/libo/svl/source/items/itempool.cxx:379: fuer Image, dort gibt es derzeit keine Statics - Bug
and so on until the 33th line
Comment 24 Julien Nabet 2012-11-20 18:41:50 UTC
New behaviour too, it crashes as usual with the window message:
The following files will be recovered,

I just clicked "OK" as usual, the window disappear so LO is stopped but right away, Writer started automatically, weird...
Comment 25 Julien Nabet 2012-11-20 18:52:05 UTC
Caolán/Michael: perhaps it could be svl/source/items/itempool.cxx from line 379 which is debug only part:
    378 #ifdef DBG_UTIL
    379         SAL_WARN( "svl.items", "fuer Image, dort gibt es derzeit keine Statics - Bug" );
    380         if ( pImp->ppStaticDefaults )
    381         {
    382             // Delete() ist noch nicht gelaufen?
    383             if ( !pImp->maPoolItems.empty() && !pImp->mpSecondary->pImp->maPoolItems.empty() )
    384             {
    385                 // hat der master SetItems?
    386                 sal_Bool bHasSetItems = sal_False;
and so on...
Comment 26 Caolán McNamara 2012-11-23 14:03:47 UTC
I can't reproduce any problem on master Linux with --enable-dbgutil (valgrind is silent too). The "fuer Image, dort gibt es derzeit keine Statics - Bug" is essentially cosmetic, someone just changed some old debugging defines to be a SAL_WARN, that's back to effectively silent SAL_INFO now.
Comment 27 Julien Nabet 2012-11-23 14:07:34 UTC
Caolán: thank you for the time spent on it.
Since nobody can't reproduce it, I'll put it RESOLVED/INVALID because it must be something buggy on my system.
Comment 28 Julien Nabet 2012-12-05 19:10:19 UTC
I'm not crazy after all! :-)

*** This bug has been marked as a duplicate of bug 57091 ***
Comment 29 Julien Nabet 2012-12-05 19:10:46 UTC
oups..

*** This bug has been marked as a duplicate of bug 57901 ***