Created attachment 835517 [details] backtrace (says to attache the coredump, but it is too large!) Description of problem: I have several uses of the MEDIAN() function in this spreadsheet, as I enter data libreoffice crashes. Version-Release number of selected component (if applicable): 4.1.3.2 (release: 8.fc19 ) How reproducible: Always. Steps to Reproduce: The following simple columns of data will repeatedly cause a crash: 23 8 21 17 27 26 OR: 12 17 6 10 11 10 12 Note, if you sort the data first then use MEDIAN() it correctly determines the value. I have tried this both in separate pages in the spreadsheet, and in a fresh (new) spreadsheet. Actual results: Expected results: Additional info:
I have attempted to submit this via abrt many times, but it will not submit? That is why I did this -- manually. The coredump was too large to upload (124MB)
Unfortunately I can't reproduce this and the backtrace is incomplete (gdb hung and killed), could you try to generate a complete backtrace?
I have repeated the process several times (same column of data), each time I get a crash. When I review the backtrace, each one ends with: Timeout exceeded: 240 seconds, killing gdb. Looks like gdb hung while generating backtrace. This may be a bug in gdb. Consider submitting a bug report to gdb developers. Please attach coredump from this crash to the bug report if you do. I am not sure how to proceed from here, I don't know any options to set in gdb. My system is up2date.
Created attachment 835996 [details] requested backtrace I generated this backtrace as part of a crash submission. It marked the bug as 1034383 and did not attach the backtrace. So I am adding it here. Additional information: I have tried this same test on 4 different machines, as different users and in different desktops (xfce, gnome, gnome classic); in each case libre office crashes (everytime) when I use MEDIAN() of the column of data [below].
*** Bug 1034383 has been marked as a duplicate of this bug. ***
23 8 21 17 27 26 =MEDIAN(<that range>) crashes reproducible as reported via 1034383
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800
hmm... * Sun Oct 20 2013 Jakub Jelinek <jakub> 4.8.2-2 - update from the 4.8 branch - PRs c++/58596, libstdc++/58800 - power8 TImode fix (#1014053, PR target/58673) which on the face of it would suggest that a rebuild with >= 4.8.2-2 would fix this. But gcc-4.8.2-1 is the latest available pushed to f19 as far as I can see so we don't have anything more recent we can rebuild against. caolanm->jakub: any workarounds, or plans to push an updated f19 libstdc++-devel ?
Why have you reassigned it to gcc? Just add karma to https://admin.fedoraproject.org/updates/FEDORA-2013-23419/gcc-4.8.2-7.fc19 and it will be hopefully pushed earlier. There is also bodhi request for F20, but that one has been already pushed stable, but is likely waiting for F20 release.
because when I searched admin I could find no f19 pending update
libreoffice-4.1.4.2-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libreoffice-4.1.4.2-2.fc20
Package libreoffice-4.1.4.2-2.fc20: * should fix your issue, * was pushed to the Fedora 20 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.4.2-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23697/libreoffice-4.1.4.2-2.fc20 then log in and leave karma (feedback).
libreoffice-4.1.4.2-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/libreoffice-4.1.4.2-2.fc19
libreoffice-4.1.4.2-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
libreoffice-4.1.4.2-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Thanks Caolan, it appears to be fixed, nice detective work.