| Summary: | REPORTBUILDER: Updating to LibO 4.0.4.2 causes any attempt to open a Base report to crash LibreOffice | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | J Liu <umn19279> |
| Component: | Base | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | blocker | CC: | bitigchi, iplaw67, lionel, serval2412, spreij |
| Priority: | highest | Keywords: | regression |
| Version: | 4.0.4.2 release | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | macOS (All) | ||
| See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=65762 https://bugs.freedesktop.org/show_bug.cgi?id=65937 |
||
| Whiteboard: | BSA | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: | Apple hang trace of soffice process | ||
Same problem exists for the release version 4.0.4 and 4.1.0.0.beta2 both with Java 7 Update 21. The bug seems not to be platform dependent as this behavior is the same in Windows 7 and Ubuntu 13.04. Version 4.0.3.3 works on both operating systems without any problem. Confirmed that the problem is not restricted to only LibreOffice 4.0.4.2 and Java 7 Update 25. The same problem is occurring on my other Mac, which has the following profile: Operating System: Mac OS X 10.6.8 Version: 4.0.4.2 (release) Java Runtime Environment: 1.6.0_51-b11-456-10M4508 I don't have any database files, but since according to comment#2, problem is reproducible, therefore setting status to "NEW". Back-revving LibreOffice to 4.0.3.3 on my machine with Mac OS 10.8.4 and Java 7 Update 25 does not cause LibreOffice to crash upon opening a report. This seems to imply that Java 7 is not the culprit, but rather is a bug that has been introduced in the LO 4.0.4. The title of this bug report has been changed accordingly. It is definitely tied to the report-builder. When I remove the report-builder the system reverts to the old inbuilt report builder. Obviously you cannot run reports built with the (Oracle) report-builder but setting up a report with the old inbuilt report builder works fine with no crashing issues. This should be a blocker. Also, I seem to recall that this has been reported for Linux 64bit too, but will have to find the dup report. Alex Adding Lionel, Julien to CC I don't get a crash on master build with OSX 10.8.4, however the app does hang.
Testing the options in the Report section of an ODB file gives :
- double-clicking on an existing report : error message that javaloader has no mapping from java to C++
- Use Wizard to Create Form : nothing happens
- Create Form in Design View : app hangs, requiring force kill
When killed, this is the trace I see :
Process: soffice [15184]
Path: /Applications/LibreOfficeDev.app/Contents/MacOS/soffice
Identifier: soffice
Version: 4.2.0.0.alpha0 (???)
Code Type: X86 (Native)
Parent Process: launchd [1043]
User ID: 501
Date/Time: 2013-06-20 18:31:33.111 +0200
OS Version: Mac OS X 10.8.4 (12E55)
Report Version: 10
Interval Since Last Report: 461131 sec
Crashes Since Last Report: 102
Per-App Crashes Since Last Report: 1
Anonymous UUID: 9F5C4B75-E194-D972-37AE-22D09B94D397
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004
VM Regions Near 0x4:
--> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] ---/--- SM=NUL /Applications/LibreOfficeDev.app/Contents/MacOS/soffice
__TEXT 0000000000001000-0000000000002000 [ 4K] r-x/rwx SM=COW /Applications/LibreOfficeDev.app/Contents/MacOS/soffice
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libuno_sal.dylib.3 0x0002c48d rtl_uString_new_WithLength + 45
1 libuno_sal.dylib.3 0x00029649 rtl_uStringbuffer_ensureCapacity + 57
2 libuno_sal.dylib.3 0x0002974d rtl_uStringbuffer_insert_ascii + 173
3 libpcrlo.dylib 0x2308a8db pcr::OBrowserLine::FullFillTitleString() + 187
4 libpcrlo.dylib 0x2308ce7f pcr::OBrowserListBox::PositionLine(unsigned short) + 191
5 libpcrlo.dylib 0x2308cf91 pcr::OBrowserListBox::UpdatePosNSize() + 81
6 libpcrlo.dylib 0x2308f8d5 pcr::OBrowserListBox::InsertEntry(pcr::OLineDescriptor const&, unsigned short) + 597
7 libpcrlo.dylib 0x231421ce pcr::OPropertyEditor::InsertEntry(pcr::OLineDescriptor const&, unsigned short, unsigned short) + 78
8 libpcrlo.dylib 0x2312ffbe pcr::OPropertyBrowserController::UpdateUI() + 462
9 libpcrlo.dylib 0x23130e9f pcr::OPropertyBrowserController::impl_rebindToInspectee_nothrow(std::vector<com::sun::star::uno::Reference<com::sun::star::uno::XInterface>, std::allocator<com::sun::star::uno::Reference<com::sun::star::uno::XInterface> > > const&) + 63
10 libpcrlo.dylib 0x23130fdd pcr::OPropertyBrowserController::inspect(com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::uno::XInterface> > const&) + 269
11 librptuilo.dylib 0x22cd4061 rptui::PropBrw::implSetNewObject(com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::uno::XInterface> > const&) + 193
12 librptuilo.dylib 0x22cd4364 rptui::PropBrw::Update(com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&) + 500
13 librptuilo.dylib 0x22ccbdb3 rptui::ODesignView::MarkTimeout(void*) + 275
14 libvcllo.dylib 0x01abb5cc Timer::Timeout() + 28
15 libvcllo.dylib 0x01abba05 Timer::ImplTimerCallbackProc() + 133
16 libvcllo.dylib 0x01e3fee1 -[TimerCallbackCaller timerElapsed:] + 81
17 com.apple.Foundation 0x947239b4 __NSFireTimer + 117
18 com.apple.CoreFoundation 0x939c7406 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
19 com.apple.CoreFoundation 0x939c6da5 __CFRunLoopDoTimer + 709
20 com.apple.CoreFoundation 0x939abbb2 __CFRunLoopRun + 1842
21 com.apple.CoreFoundation 0x939ab01a CFRunLoopRunSpecific + 378
22 com.apple.CoreFoundation 0x939aae8b CFRunLoopRunInMode + 123
23 com.apple.HIToolbox 0x9253ef5a RunCurrentEventLoopInMode + 242
24 com.apple.HIToolbox 0x9253ebf5 ReceiveNextEventCommon + 162
25 com.apple.HIToolbox 0x9253eb44 BlockUntilNextEventMatchingListInMode + 88
26 com.apple.AppKit 0x96ca593a _DPSNextEvent + 724
27 com.apple.AppKit 0x96ca516c -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119
28 libvcllo.dylib 0x01e04c47 AquaSalInstance::Yield(bool, bool) + 487
29 libvcllo.dylib 0x01ab3c74 Application::Yield(bool) + 84
30 libvcllo.dylib 0x01ab3d2c Application::Execute() + 60
31 libsofficeapp.dylib 0x000a256c desktop::Desktop::Main() + 7596
32 libvcllo.dylib 0x01aba312 ImplSVMain() + 226
33 libvcllo.dylib 0x01e03fa1 AquaSalInstance::handleAppDefinedEvent(NSEvent*) + 129
34 libvcllo.dylib 0x01e40b5b -[VCL_NSApplication sendEvent:] + 123
35 com.apple.AppKit 0x96c9b62c -[NSApplication run] + 951
36 com.apple.AppKit 0x96c3e5f6 NSApplicationMain + 1053
37 libvcllo.dylib 0x01e04867 ImplSVMainHook(int*) + 343
38 libvcllo.dylib 0x01aba34a SVMain() + 26
39 libsofficeapp.dylib 0x000d1ff5 soffice_main + 325
40 org.libreoffice.script 0x00001f4e main + 30
41 org.libreoffice.script 0x00001f25 start + 53
(In reply to comment #8) > - Use Wizard to Create Form : nothing happens > - Create Form in Design View : app hangs, requiring force kill > > Sigh, that should be : - Use Wizard to create REPORT : no reaction, nothing happens - Create REPORT in Design View : app hangs. Alex Created attachment 81125 [details]
Apple hang trace of soffice process
FWIW, I do also get a hang condition in the Form creation wizard... Could be the same issue as in bug 65937. Adding linkage in "See Also" section. Seems to be the same as https://bugs.freedesktop.org/show_bug.cgi?id=65762 There it is reported for Linux. Only LO 4.0.4.2 will crash, when a report should be executed or should be edited. LO 4.1.0.0 Beta 2 works ..., also LO 4.0.3.3 *** This bug has been marked as a duplicate of bug 65762 *** |
Problem description: After installing Java 7 Update 25, any attempt to open a report in Base causes LibreOffice to crash. Steps to reproduce: 1. Open any previously written report in a Base document. Operating System: Mac OS X Version: 4.0.4.2 rc Last worked in: 4.0.3.3 release