Created attachment 797163 [details]
File: backtrace

Created attachment 797164 [details]
File: cgroup

Created attachment 797165 [details]
File: core_backtrace

Created attachment 797166 [details]
File: dso_list

Created attachment 797167 [details]
File: environ

Created attachment 797168 [details]
File: exploitable

Created attachment 797169 [details]
File: limits

Created attachment 797170 [details]
File: maps

Created attachment 797171 [details]
File: open_fds

Created attachment 797172 [details]
File: proc_pid_status

Created attachment 797173 [details]
File: var_log_messages

Do you know how to reproduce this ?

Not really. I think it happened twice, while viewing two documents with many SVGs. But ATM I'm not able to trigger it again. I can send you the documents privately if you want to try...

Seen in twice in a row again, but I cannot reproduce it when I try to...

I see this error also. I can reproduce it by inserting large TIFF files (15mb) into a .doc file.

That's encouraging, can I get a link to an example large TIFF which triggers this ?

Tried various combinations of tiffs and overlapping tiffs without success :-(

Created attachment 811808 [details]
Reproducer

Coalan, here comes the reproducer. Reopen, please.

1) Open in Writer, select "Singer’s Utilitarianism" from H1 on first line and copy to clipboard. Move to line starting with "Singer, and Regan...", it's H2. Select the whole heading (I do that by Shift-End if that matters) and paste by Ctrl-V.

2) It does for me a strange thing -- it enters a page break so the former H2 is now H1 "Singer’s Utilitarianism" and starts second page. Press Ctrl-Z (undo).

3) Crash.

Let me know if that works for you. It looks like ABRT is able to create a backtrace but is unable to post it here IMHO because of the CLOSED state.

Is it reproducible what's in comment 18? Can someone reopen this bug, please?

Fantastic! ;-) With your instructions I can reproduce the crash.

It does not happen immediately, though, there is a 1 second lag. I think this is related to the redraw that the removal of the page break creates. (In my case, the redraw happens because of scrolling in a long document with many images.)

And the good new is, I can also reopen the bug...

Grr, I can reproduce on little unsuitable-for-debugging 32bit laptop, but not on 64bit setup-perfectly-for-debugging desktop.

"1 second lag" plus reproducible on 32bit but not 64bit sounds like memory exhaustion.

Right, there's a 1 s lag. I can reproduce that on x86_64.

I get the bug on 64-bit too, and not exactly a slow machine (2.40GHz i5). Yours must be really too fast! Maybe try to run in in Valgrind to make it slower... ;-)

*** Bug 1027415 has been marked as a duplicate of this bug. ***

In my case there are no images at all. Just text (like in a book).
When I select a portion of text and move it in another position inside the page, the writer crash producing that bug data. It's so reproducible that I cannot continue to work because of it.

When I came back to home, I will try to make a file that reproduce the problem without add here the original file (I can't do it) and add it here.

At the moment that problem does not appear anymore, even on the original file.

(In reply to Valerio De Angelis from comment #27)
> At the moment that problem does not appear anymore, even on the original
> file.
Countermand: the problem is still there. It appears when I move or copy/paste large portion of text.

All i know is that i was editing a document and poof. I believe i was cutting/pasting.
Other programs that were open are Dolphin and FireFox. also i seem to have a different set of icons in LibreOffice, and earlier when i was changing the font type it was acting buggy, also in Calc i lost all my formated coloring and the answer to all the calculations were missing. Today is the first time i have used LibreOffice sence an update the other day.
oh, the data in the document has definisions from KDictionary widget off the task bar.

reporter:       libreport-2.1.9
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin --writer /home/david/Documents/emotional_control_1_32.odt --splash-pipe=5
crash_function: Window::GetWindow
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.11.7-200.fc19.x86_64
package:        libreoffice-core-4.1.3.2-4.fc19
reason:         Process /usr/lib64/libreoffice/program/soffice.bin was killed by signal 11 (SIGSEGV)
runlevel:       N 5
type:           CCpp
uid:            1000

Today this crash happened to me twice in a row, in about 20 minutes.
I am operating on Fedora 19 (KDE) since 2 days, and several other programs running, scattered on 3 desktops out of 4, that is: 2 instances of Dolphin; Thunderbird; Evince (just 1 file open); Firefox (9 tabs open).
Libre Office had 2 ODT-files open; the one I was working on was very rich in comments, and I was streamlining it by cutting and pasting more or less large portions of text inside it.
Unfortunately, I have no guess as how to reproduce it.

(In reply to Alex from comment #30)
> Today this crash happened to me twice in a row, in about 20 minutes.
> I am operating on Fedora 19 (KDE) since 2 days, and several other programs
> running, scattered on 3 desktops out of 4, that is: 2 instances of Dolphin;
> Thunderbird; Evince (just 1 file open); Firefox (9 tabs open).
> Libre Office had 2 ODT-files open; the one I was working on was very rich in
> comments, and I was streamlining it by cutting and pasting more or less
> large portions of text inside it.
> Unfortunately, I have no guess as how to reproduce it.

ok, third time today - I think it is enough, will try to close and restart my Linux box.
May it depend on the presence of certain "reserved" spots in the LO file, which usually cannot be touched on (a signal pops us, stating this)?
I'm sorry I cannot write it down, as my version is Italian...

(In reply to Alex from comment #31)

> ok, third time today - I think it is enough, will try to close and restart
> my Linux box.
> May it depend on the presence of certain "reserved" spots in the LO file,
> which usually cannot be touched on (a signal pops us, stating this)?
> I'm sorry I cannot write it down, as my version is Italian...

it seems it has nothing to do with the overall setup: as a matter of fact, I closed everything, launched Apper to update the system and rebooted when it was over.
Now I have opened the same ODT file (now Dolphin is only running) and I crashed at the same point where it did last time - I cut some 20 lines to paste them in another paragraph in the same file.
So the problem is in Libre Office, I'm afraid...

Alex: Consider reading this bug from comment #18 on. We have a reproducer (feel free to try it), thought no one is able to debug the problem.

I tried to reproduce the bug with the comment 18's attachment but it doesn't appear on my system.

LibreOffice 4.1.3.2-4.fc20
Linux 3.11.8-300.fc20.x86_64
4.11.3
4 GB RAM

(In reply to Michal Nowak from comment #33)
> Alex: Consider reading this bug from comment #18 on. We have a reproducer
> (feel free to try it), thought no one is able to debug the problem.

what David Gilmore writes in comment # 29 suits my own experienc: I was working hard on a file, editing it thoroughly and cutting-pasting and all that.
I also had Dolphin and Firefox running, but my impression is that the problem lies with something inside LibreOffice.

BTW, I have tinkered with the attachment in comment # 18 but when I try to past "Singer’s Utilitarianism" onto the following title, nothing happens - sorry :-(

At present I am using LO  4.1.3.2-4.fc19, that is, customized for Fedora 19, Kernel is 3.11.8-200.fc19.x86_64

Alex: Is your LO official Fedora package?

I still can crash LO with my reproducer, even with clean LO profile however, it won't crash if LO is started off from Tor Browser Bundle (that is go to the reproducer with TBB, open it in LO Writer from TBB and try the test case -- it won't crash). The difference here is that TBB sets $HOME to it's $PWD so equivalent of /home/$USER/.config is empty.

Milan, can you reproduce with new user account?

(In reply to Michal Nowak from comment #36)
> Alex: Is your LO official Fedora package?

sure it is! BTW, I have no non-standard Fedora repos...

> I still can crash LO with my reproducer, even with clean LO profile however,
> it won't crash if LO is started off from Tor Browser Bundle (that is go to
> the reproducer with TBB, open it in LO Writer from TBB and try the test case
> -- it won't crash). The difference here is that TBB sets $HOME to it's $PWD
> so equivalent of /home/$USER/.config is empty.
> 
> Milan, can you reproduce with new user account?

however, since comment # 18 my Linuxbox underwent at least an extensive update

On F20, I can't reproduce with the document from comment #18 on F20 but I saw this crash with another document.

I'm no longer able to reproduce to crash with 4.1.3.2 on F19 using instructions from comment 18. Just an idea: the crash might only happen when LO is slowed by lack of free RAM. Every time I got the crash, I was working with R with large datasets and I was low on free RAM. That may explain why it's hard to reproduce. (I've try running LO in Valgrind and it does not help...)

I still get the crash with libreoffice-4.1.3.2-5.fc19.x86_64. Having some 4 GB of RAM available (plus 7 GB of swap).

Build ID: 4.1.3.2-10.fc20.x86_64
4 GB of ram.
The problem is still here.

Another user experienced a similar problem:

I edited an existing ODT document with Edit/Changes/Record switched on. LibreOffice suddenly crashed.

reporter:       libreport-2.1.10
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin Env_drivers_of_WNV_8.odt --splash-pipe=5
crash_function: Window::GetWindow
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.12.5-200.fc19.x86_64
package:        libreoffice-core-4.1.4.2-2.fc19
reason:         soffice.bin killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1338

Another user experienced a similar problem:

LO Writer collapsed after I pressed the UNDO button - in the ribbon - several times.

reporter:       libreport-2.1.11
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin --writer file:///run/media/wh/Buffalo1Tb/OFFSHORE/Hoofdstukken/PART_2/H4/H4draft-def_V1.odt --splash-pipe=5
crash_function: Window::GetWindow
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.12.6-300.fc20.x86_64
package:        libreoffice-core-4.1.4.2-2.fc20
reason:         soffice.bin killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

Another user experienced a similar problem:

I left my PC suspended in RAM overnight (as I usually do), with two programs open: Firefox and Dolphin (I use Kde 4). When I awoke the machine, I opened Libre Office and started working on a ODT file which had already been created days before. I pressed a combination of keys which unexpectedly shut LO, without saving the ODT file. Unfortunately, I cannot say which were those keys. That's all

reporter:       libreport-2.1.11
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin --nologo --nodefault --nolockcheck --accept=pipe,name=-276805888;urp;
crash_function: Window::GetWindow
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.12.8-300.fc20.x86_64
package:        libreoffice-core-4.1.4.2-5.fc20
reason:         soffice.bin killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            1000

Good news (or Bad news?):
the new version 4.2 not only reproduce the bug but now it happens every time.
I just open my big ODT file, go in menù -> tools and LO crash instant.
Reproducible always.

The problem is that I'm not authorized to attach here that file, is cover by copyright, unfortunately.

I'm trying to make a similar file, in similar dimension, using a similar package of features (comments, several style, footnote, etc.) but that I'm able to attach here. I had no luck so far, the file do not crash LO yet. 

Ah, as a side note, the file that reproduce the bug come from the 1st LO release and then it is passed through all the versions released so far. Instead the new file is a child of LO 4.2 only. Just in case that can make any difference.

Alternatively I can try to debug my LO, but I'm not an expert on this kind of task, sorry.
I will try after reading in the internet how to proceed.

Interesting. Are you able to reproduce the problem using the file from Comment 18?

(In reply to Milan Bouchet-Valat from comment #46)
> Interesting. Are you able to reproduce the problem using the file from
> Comment 18?
I tested it right now. The undo works perfectly and LO doesn't crash.
It is something really insidious because with a previous version of my file (800 pages, comments, notes etc.) there is no problem. I have no idea what could be, really.

found it eventually, nearly killed me :-)

Thanks!

What about LibreOffice 4.2 from Fedora 20? I somehow reproduced the crash (see https://retrace.fedoraproject.org/faf/reports/369731/), thought it seems the reproducer is not 100% reliable on 4.2.

4.2 is affected by this problem as well and I'll have an update for that when it finished building

Congrats! So now do you understand why it was so hard to reproduce? :-)

What was the problem? I'm very curious considering how hard to reproduce it was.

*** Bug 1071597 has been marked as a duplicate of this bug. ***

libreoffice-4.1.5.3-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libreoffice-4.1.5.3-4.fc19

Package libreoffice-4.1.5.3-4.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreoffice-4.1.5.3-4.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-3458/libreoffice-4.1.5.3-4.fc19
then log in and leave karma (feedback).

Just to confirm that, to me, this bug is fixed.
I have no more that problem in Build ID: 4.2.3.3-9.fc20 with the same file that continuously crashed before.

Thank you!