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
Created attachment 69374 [details] valgrind logs I reproduced the problem and retrieved valgrind trace
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?
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
Created attachment 69380 [details] Additional Sample Document Currently I do no know what in the Drawings causes the crash.
(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.
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.
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.
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.
(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!
Pushed; thanks ! :-)
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.
Worls fine without crashing for Version 4.0.0.0.alpha0+ (Build ID: 04f2f0).
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?
Following my last comment, I reopen this tracker badfully
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?
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
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
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.
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?
> 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 !
Michael: master sources for the test have been retrieved until http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd91019804398c0643951eb291a45d3931968ae3. It still crashes :(
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)
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
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...
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...
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.
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.
I'm not crazy after all! :-) *** This bug has been marked as a duplicate of bug 57091 ***
oups.. *** This bug has been marked as a duplicate of bug 57901 ***