Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | HelpLinker crash on building khmer content | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Build Tools | Reporter: | pavel | ||||||
Component: | code | Assignee: | caolanm | ||||||
Status: | CLOSED FIXED | QA Contact: | issues@tools <issues> | ||||||
Severity: | Trivial | ||||||||
Priority: | P1 (highest) | CC: | issues, khirano, maho.nakata, ruediger.timm | ||||||
Version: | 680m219 | ||||||||
Target Milestone: | OOo 2.3 | ||||||||
Hardware: | PC | ||||||||
OS: | Linux, all | ||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
Developer Difficulty: | --- | ||||||||
Attachments: |
|
Description
pavel
2007-07-11 20:26:00 UTC
Exactly the same crash on unxmacxi.pro. Other languages are OK. Only km looks somehow problematic. Caolan: do you haev any idea? *** Issue 79307 has been marked as a duplicate of this issue. *** pavel, there are many gsicheck problems in that file. Maybe thats the reason the linker crashes. some of them can be fixed automatically with latest gsicheck (included in your build already) but many would have to get fixed manually gh: may be. But this is in my opinion different problem. Maho reported it even on the merged Khmer translations... rt: can you please reproduce this in your environment as well? Just build Khmer (km) helpcontent2. km eh, let me configure to build that and I'll take a look. hmm, error 139 on solaris intel, sbasic_en-US.zip... maybe it's just having lots of languages? btw., a cws based on m219 something unrelated here. dies in ucnv_close in the dtor of tokenizer. Created attachment 46716 [details]
does this work for everyone
The code in the HelpLinker is lifted from the java one, so I suspect that the same thing happens in the java one, except perhaps silently caught as an exception somewhere. khmer has no direct space thing, so here we get some really big strings, for whatever original impl reasons we're limited to 250 char long index strings. If bigger we clip them, but we look them up in the cache before clipping, leading to a string being mapped to an id, but not being found under that id later. So, if we're going to clip a string, we need to do it before we look it up and/or subsequently store it. km build OK here with the patch - thanks! Tested on Solaris Sparc: build in unmodified environment breaks as described. Patch helps, dmake succeeds now. Masterfix? masterfix sounds good to me. but I suggest the following patch. hjs reports an additional problem with the static object dtor on solaris. I see no reason why there *should* be a problem, but there are no ill side-effects of skipping dropping the troublesome resources on exit. Created attachment 46722 [details]
patch, + hjs problem
fixed in master Khmer crash is gone in SRC680_m221. Closing. |