| Summary: | REPORTBUILDER: Resizing zero height section causes LibreOffice to crash | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | J Liu <umn19279> |
| Component: | Base | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | barta, lo_bugs |
| Priority: | medium | ||
| Version: | 4.0.0.3 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | macOS (All) | ||
| Whiteboard: | BSA | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
Bug reproduction example
typescript two SIGSEGV's and gdb backtrace JRE error report typescript with segfault before report design window; backtrace |
||
Created attachment 80573 [details]
typescript two SIGSEGV's and gdb backtrace
I tried to reproduce this on Linux, but I did not get past step 3--or
maybe not even beyond step 2.
The right click in step 3 failed to display the pop-up menu. I saw
that LibreOffice was pegging the CPU, and after 3 or 5 minutes of
this, I typed ctrl-C in the terminal. Resulting error messages in the
terminal include a SIGSEGV in the Java Runtime and a SIGSEGV in
OUString::equals.
The present attachment includes a gdb backtrace from OUString::equals;
I shall soon attach the error report from the Java Runtime.
I am leaving bug status UNCOMFIRMED because it is not clear that my
crash is the same crash that the original reporter saw.
My LibreOffice is master 45abf35, pulled 2013-05-29, configured as
--enable-option-checking
--enable-dbgutil
--enable-crashdump
--disable-build-mozilla
--without-system-postgresql
--without-myspell-dicts
--without-help
--with-extra-buildid
built and running on ubuntu-natty (32-bit)
$ uname -a
Linux cougar-natty 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 18:00:43 UTC 2012 i686 athlon i386 GNU/Linux
$ gcc --version
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.5) (6b24-1.11.5-0ubuntu1~11.04.1)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
Created attachment 80574 [details]
JRE error report
Created attachment 80923 [details]
typescript with segfault before report design window; backtrace
This time running under gdb (I wanted to help, not to complicate the
issue. Honest!), I got a segfault before the the rogram displayed the
report design window.
Interesting... Well, for comparison, my Mac is running Java 7 (it was Update 21 when I filed the bug, but it was upgraded to Update 25 yesterday). If I have time, I will try to open the file on a Linux machine at my work. However, I don't know how useful that would be, since we have RHEL machines where I work. At the very least, it might give an extra data point. J Liu: tried reproducing but failing at step 3. Don't see any edit option in the lower right: http://cl.ly/image/3Q3v0J3S1A0k Setting to NEEDINFO until more detail is provided. After providing the requested info, please reset this bug to UNCONFIRMED. Thanks :) I think the STR, in a bit more detail go like this:
2. In the left pane, click icon "Reports". Program presents list of
reports in the lower right pane.
3.1 In the list of reports, right-click Assets, which happens to be
only report. Program presents pop-up menu.
3.2 In the pop-up menu, click Edit. Program presents Report Designer
window "reportbuilderSectionResuzeBug.odb : Assets".
For me now, the Report Designer window opens already showing
properties of the page footer in its right pane. This is a bit
different from what I think I remember from June, but my memory could
well be wrong.
I have managed to increase the height of the page footer directly to
one inch without causing a crash using a degug build of master commit
b092637, fetched 2013-12-06, built and running on debian-wheezy. So
my segfault from last June has gone away. Of course, it was never
clear whether my segfault was the same crash that J Liu reported.
In the hope that I have answered Foss' question, I am setting bug
status back to UNCONFIRMED.
(In reply to comment #0) > > .... > > Operating System: Mac OS X > Version: 4.0.3.3 release did you try recent LibO 4.1.3.2 final release? is the bug still there after upgrade? WFM in version: 4.4.0.0.alpha0+ Build ID: a24139dafdf044b319bbf7c8e6fb34ee7b0c139d not reproducible on OSX 10.9.4 Not reproducible on Version: 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8 closing as wfm |
Created attachment 80293 [details] Bug reproduction example Problem description: If you set a section (i.e., Page Header, Page Footer, Report Header, etc.) to have 0.00" height, and then later decide to increase the height to something non-zero, in certain circumstances, you can cause LibreOffice to crash. Steps to reproduce: 1. Open attachment 'reportbuilderSectionResizeBug.odb'. 2. In the left pane, click "Reports". 3. In the lower-right pane, right-click and choose "Edit". 4. Right-click the "Page Footer" section, and choose "Properties". 5. In the "Height" property, you can set the height to anything between 0.00" and 0.28" without causing LibreOffice to crash. However, if you try to set any value that is 0.29" or larger, LibreOffice will crash. Interestingly, there is a "workaround" that prevents LibreOffice from crashing. If you set a height to something between 0.00" and 0.28", and then save the report, save the database, quit LibreOffice, and then reopen the database, you can then proceed to increase the value of the height to larger than 0.29". On the other hand, if you set the height to something between 0.00" and 0.28" and save everything, but then try to increase the height to larger than 0.29" WITHOUT closing LibreOffice, it will still cause LibreOffice to crash. Operating System: Mac OS X Version: 4.0.3.3 release