Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Writer crash related to input fields | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Writer | Reporter: | mux2005 <mux2005> | ||||||
Component: | programming | Assignee: | AOO issues mailing list <issues> | ||||||
Status: | CONFIRMED --- | QA Contact: | |||||||
Severity: | Trivial | ||||||||
Priority: | P3 | CC: | issues, michael.haus | ||||||
Version: | OOo 2.4.0 | Keywords: | oooqa | ||||||
Target Milestone: | --- | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
Developer Difficulty: | --- | ||||||||
Issue Depends on: | |||||||||
Issue Blocks: | 90439 | ||||||||
Attachments: |
|
Description
mux2005
2008-10-23 13:48:58 UTC
Created attachment 57413 [details]
See issue description.
The NOTE about WollMux's activity is missing the text "while preparing its form GUI". The point I'm trying to make is that whatever UNO calls cause the corruption, do not happen while/after you press "Okay" but before you make your first click. Reassigned to ES. @mux2005: can you still reproduce this in a current version? @es: Yes, I can reproduce the crash with m8 exactly as described. The URL of the .tar.gz has changed, though. This page has the current links: http://forge.osor.eu/frs/?group_id=11 The crash can also be reproduced without installing the uno.pkg extension. To do this, change the instructions as follows 1. Instead of WollMux.uno.pkg download version 5.9.3 of WollMuxBar.jar from http://forge.osor.eu/frs/?group_id=11 4b. After the normal step 4, edit the wollmux.conf to add the following line at the end ALLOW_EXTERNAL_WOLLMUX "true" 5.-7. Instead, after closing all OOo instances launch java -jar WollMuxBar.jar This will start OOo via the bootstrap mechanism. The dialog described in step 8. will pop up. The remaining steps are the same. -------- As you can see even when just communicating with OOo via the socket connection, it will crash. In this scenario there's none of our code executing in OOo's JVM. As you will also notice, in this scenario OUR GUI remains even after OOo crashes, because it's not our Java code that crashes. I can confirm that this can be reproduced with 3.1.1 as above. Doesn't happen if I just open the .ott and click through the input field popups, but it does if I launch it according to the report and then click through. When I do that I see a NULL returned from pEndFrm->FindFlyFrm which is then dereferenced and placed in the aSortedObjs Attached patch adds an ASSERT there to help catch it. (and hacks around the immediate crash by avoiding placing the NULL into aSortedObjs) Created attachment 67855 [details]
avoids immediate crash, pinpoints insertion of NULL into aSortedObjs which is where the later crash originates
Reset assigne to the default "issues@openoffice.apache.org". |