|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Insert a callout and enter characters, save and reload -> Crash | ||
|---|---|---|---|
| Product: | Writer | Reporter: | amy2008 <amy2008> |
| Component: | code | Assignee: | wolframgarten |
| Status: | CLOSED FIXED | QA Contact: | issues@sw <issues> |
| Severity: | Trivial | ||
| Priority: | P2 | CC: | issues, Mathias_Bauer, ooo.redflag, peter.junge, stefan.baltzer |
| Version: | OOO310m9 | Keywords: | regression |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
| Issue Depends on: | |||
| Issue Blocks: | 84405 | ||
|
Description
amy2008
2009-04-21 10:22:00 UTC
For verticval callouts, CJK support must be enabled. But with standard (horizontal) callouts the problem is the same. The critical part is that the cursor must be in the callout (NOT in text body) when saving and reloading the file. Reproducible on Win, Solaris, Mac OS X. Adjusting summary. This was OK in OOo 3.0.1. -> Set keyword "regression" With DEV300_m46, I sometimes even get a "pure virtual function call". SBA->OS: Spoke to MBA. Similar problem as in issue 100472 (...Pool of item set deleted...). But maybe not in the same situation, thus maybe not a duplicate. Please proceed, thx. *** Issue 100472 has been marked as a duplicate of this issue. *** ->aw: In issue 100472 you commented about the problem of the order of removed pools. The problem seems to be that the BinTextObjects register at the SwAttrPool (Writers default pool) while the items in all the SfxItemSets of drawing objects are pooled within a secondary pool. The secondary pools are removed in SwDoc::ReleaseDrawModel() from ~SwDoc(). At this time the pooled items are deleted. Later in SwDoc::~SwDoc() the Writer pool is removed. At this time the BinTextObject tries to copy attributes that do not exist anymore. Either the BinTextObjects find a way to register at the correct SfxItemPool or there needs to be an additional step to get rid of the SfxItemPoolUsers before the secondary pools are deleted. I suggest the latter. The ID of the error report is rqtt8kc. I just receive the error report id. Li Meiying *** Issue 102435 has been marked as a duplicate of this issue. *** AW->OS: Thanks for fiddlig out what happens. Adding to aw073... AW: Looking in SW where the pool destruction starts, getting SW and building with debug. Also getting tools and building with debug... AW: In SwDoc::ReleaseDrawModel() the three used pools are decoupled and deleted (the DRawingLayer one even gets an extra pSdrPool->Delete(); this should not be needed nowadays, but who knows). The simplest solution is to try to register/look for an EditEngineItemPool in BinTextObject::BinTextObject to register at, so the pool to be copied will not be deleted (but decoupled). Trying this shows that it works and avoids copying an already deleted SfxItemPool (BinTextObject's which got constructed with a SwAttrPool directly). Also thinking about adding a static, ref-counted EditEngineItemPool as single to-be-used instance when ownership is needed... AW: static, ref-counted EditEngineItemPool has dies due to various possible basic metric values in the pool, so it is not possible to create a single global one which will be usable in all cases. Back to the simple case: Use a local pool when given one is null or not a EditEngineItemPool or has on Sub-pool which is a EditEngineItemPool. Works well. AW: Okay, done. AW: Checked on installed Win32 install set, works as expected. AW->WG: Please verify (as initially described) *** Issue 103256 has been marked as a duplicate of this issue. *** *** Issue 103507 has been marked as a duplicate of this issue. *** @wq: could you please verify that this issue is a duplicate to issue 103507 by testing if the fix from aw also fixes that issue? Verified in CWS. *** Issue 103654 has been marked as a duplicate of this issue. *** Verified in DEV300m54 on WinXP Closing *** Issue 104669 has been marked as a duplicate of this issue. *** *** Issue 101905 has been marked as a duplicate of this issue. *** |