Apache OpenOffice (AOO) Bugzilla – Issue 7161
OOO_STABLE_1/X11: (sal+tools) nlsupport unimplemented
Last modified: 2004-03-25 07:37:46 UTC
In the latest dev alpha release there's a repeatable crash as follows: 1. Open swriter 2. Open "Tools->Options..." window 3. Expand "Load/Save" 4. Click on "HTML Compatability" 5. Crash Looks like its caused by the call to strlen in rtl_getTextEncodingFromMimeCharset (tencinfo.c) and the fact that we're giving it a charset of RTL_TEXTENCODING_DONTKNOW from our unimplemented nlsupport (seems like this could potentially affect all platforms). Anyway, changing our osl_getTextEncodingFromLocale in nlsupport to return RTL_TEXTENCODING_ISO_8859_1 fixes the problem but probably isn't a great long term solution. Backtrace: Program received signal EXC_BAD_ACCESS, Could not access memory. 0x70000a50 in strlen () (gdb) bt #0 0x70000a50 in strlen () #1 0x002c2ad4 in rtl_getTextEncodingFromMimeCharset () #2 0x03672f70 in FillWithMimeAndSelectBest__18SvxTextEncodingBox () #3 0x023a2a78 in __14OfaHtmlTabPageP6WindowRC10SfxItemSet () #4 0x023a2c40 in Create__14OfaHtmlTabPageP6WindowRC10SfxItemSet () #5 0x02382634 in CreateTabPage__17OfficeApplicationUsP6WindowRC10SfxItemSet () #6 0x023a5820 in ShowPageHdl_Impl__20OfaTreeOptionsDialogP13SvTreeListBox () #7 0x04a55028 in SelectHdl__6SvLBox () #8 0x04a60538 in Select__13SvTreeListBoxP11SvLBoxEntryUc () #9 0x04a58040 in SetCursor__9SvImpLBoxP11SvLBoxEntryUc () #10 0x04a5c2dc in SetCursorAtPoint__11ImpLBSelEngRC5PointUc () #11 0x00deeb18 in SelMouseButtonDown__15SelectionEngineRC10MouseEvent () #12 0x04a5b53c in MouseButtonDown__9SvImpLBoxRC10MouseEvent () #13 0x04a60968 in MouseButtonDown__13SvTreeListBoxRC10MouseEvent () #14 0x00e242a4 in ImplHandleMouseEvent__FP6WindowUsUcllUlUsUs () #15 0x00e28be4 in ImplHandleSalMouseButtonDown__FP6WindowP13SalMouseEvent () #16 0x00e273c4 in ImplWindowFrameProc__FPvP8SalFrameUsPCv () #17 0x00e92e14 in Call__C12SalFrameDataUsPCv () #18 0x00e8ed4c in HandleMouseEvent__12SalFrameDataP7_XEvent () #19 0x00e91730 in Dispatch__12SalFrameDataP7_XEvent () #20 0x00eb7f28 in Dispatch__10SalDisplayP7_XEvent () #21 0x00eb7c48 in Yield__10SalDisplayUc () #22 0x00eb3b7c in DisplayYield__FiP10SalDisplay () #23 0x00eb290c in Yield__7SalXLibUc () #24 0x00eba90c in Yield__11SalInstanceUc () #25 0x00d2d324 in Yield__11Application () #26 0x00de1254 in Execute__6Dialog () #27 0x02383450 in ExecuteGeneralOptionsDialog__17OfficeApplicationUs () #28 0x0237f254 in ExecuteApp_Impl__17OfficeApplicationR10SfxRequest () #29 0x02373f34 in SfxStubOfficeApplicationExecuteApp_Impl__FP8SfxShellR10SfxRequest () #30 0x02cd6778 in CallExec__8SfxShellPFPB0R10SfxRequest_vRB2 () #31 0x02cbc4a0 in Call_Impl__13SfxDispatcherR8SfxShellRC7SfxSlotR10SfxRequestUc () #32 0x02cbdf04 in _Execute__13SfxDispatcherR8SfxShellRC7SfxSlotR10SfxRequestUs () #33 0x02cdae90 in Execute_Impl__11SfxBindingsR10SfxRequestPC7SfxSlotP8SfxShell () #34 0x02cda6fc in Execute_Impl__11SfxBindingsUsPPC11SfxPoolItemUsUsPPCB1 () #35 0x02cda1a8 in Execute__11SfxBindingsUsPPC11SfxPoolItemUsUsPPCB1 () #36 0x02cfcc6c in Select__14SfxVirtualMenuP4Menu () #37 0x02cfca30 in LinkStubSelect__14SfxVirtualMenuPvn1 () #38 0x00de5794 in Select__4Menu () #39 0x00de7fd0 in ImplCallSelect__4MenuPB0 () #40 0x00e279c0 in Call__C4LinkPv () #41 0x00e26b5c in ImplHandleUserEvent__FP11ImplSVEvent () #42 0x00e27798 in ImplWindowFrameProc__FPvP8SalFrameUsPCv () #43 0x00e92e14 in Call__C12SalFrameDataUsPCv () #44 0x00e911d4 in HandleClientMessage__12SalFrameDataP19XClientMessageEvent () #45 0x00e91c74 in Dispatch__12SalFrameDataP7_XEvent () #46 0x00eb7f28 in Dispatch__10SalDisplayP7_XEvent () #47 0x00eb7c48 in Yield__10SalDisplayUc () #48 0x00eb3b7c in DisplayYield__FiP10SalDisplay () #49 0x00eb290c in Yield__7SalXLibUc () #50 0x00eba90c in Yield__11SalInstanceUc () #51 0x00d2d324 in Yield__11Application () #52 0x00d2d1b0 in Execute__11Application () #53 0x00008470 in ?? () #54 0x00d31978 in SVMain__Fv () #55 0x00eb1b9c in main () #56 0x000026b0 in ?? () #57 0x000024e0 in ?? () (gdb)
This problem is also evident in linux (running RedHat 7.2). Steps: 1. in shell, export LC_ALL="baltic" 2. Open swriter 3. Open "Tools->Options..." window 4. Expand "Load/Save" 5. Click on "HTML Compatability" 6. Crash
Hi, in the porting project (dev@porting) there was a long discussion about this problem and several porters contributed their input. I think, Oliver is the maintainer of this code (nlsupport.c). Oliver, could you help here?
I can't do anything about this: there will always be textencodings we don't have mappings for. on the other hand, the office should not crash because of this. So this should definitly be fixed in the SvxTextEncodingBox, which feeds rtl_getTextEncodingFromMimeCharset with a NULL pointer here. Eike, are you the actual owner of this code ?
Hi, Eike is on vacation this week. Don't expect his feedback before beginning of next week.
accepted
Eike, Can you reassign to me? I've got patches that correct this problem and correctly implement locale support on MacOS X and Darwin. They will be going into our X11 beta in a week and I'm just cleaning them up now... Dan
Attached patch from 10/01/02 implements MacOS X/Darwin nlsupport. It uses the system call CFStringGetSystemEncoding() from CoreFoundation to return the current system text encoding, and translates that encoding into an RTL text encoding. We use the _pair_search() and other routines to search through the lookup tables to find the RTL text encoding. We also use some of the Linux _nl_language_list structure for searching as well, and supplement that with a MacOS X/Darwin specific list. On MacOS X (well, the Quartz/Aqua port really) we use a CoreFoundation call to return the IANA charset encoding name which then gets looked up in our tables, but on Darwin this call doesn't exist so we implement it manually with a big switch{}. This patch corrects all known text-encoding-related crashes and freezes, including the HTML Compatibility crash. Cheers, Dan
Created attachment 3035 [details] cd SRC_ROOT/sal, patch -p0 < /path/to/patchfile, rebuild sal
Request approval for this patch for commission to OOO_STABLE_1_PORTS and others. Please add keyword "approval_pending". ----- PLEASE VERIFY SAFENESS ON OTHER PLATFORMS ----- Dan
@Dan: reassigning to you as requested
Created attachment 3054 [details] Implements locale retrieving using Java (for experimentation only). Includes previous patch and sal patches in issue 7458. Apply to clean checkout of sal using the following commands: cd $SRC_ROOT/sal ; patch -p0 < /path/to/patch/file
Created attachment 3066 [details] Adds JavaVM framework to static linking of tools. Apply this patch to a clean checkout of the tools module using the following commands: cd $SRC_ROOT/tools ; patch -p0 < /path/to/patch/file
reassigning to me :)
Fine, take it. I never really wanted it anyway :) Seriously, I'm looking at CFPreferences methods of implementing non-Java locale discovery. Using the "AppleLanguages" preference value we can pull out the preferred language. Suggestion from Greg Parker. Anyway, use this issue to implement Patrick's locale method, and I'll file a new one for conversion to CFPreferences and track those changes there. Dan
Oh dude...I never mean to imply i was taking it to fix it ;) I just went through and assigned bugs to me to help me out in keeping track of all of them without resoring to figuring out IZ's query stuff. You can have it back if you want. The CFPreferences stuff does sound like a better approach...I really feel we shouldn't need Java to do locale detection. Thankfully Java is integrated nicely with OS X so it's not as big of an issue like on other platforms :)
Nah, I was just joking. This issue should get approved, committed, and closed. We can open another one to take care of further improvements (ie locale detection w/o Java). That will take a bit of time however. Dan
Created attachment 3677 [details] cd to SRC_ROOT/sal, patch -p0 < /path/to/patchfile
Ed/Kevin, Can you guys sign off on the 111902 sal patch? If so I'll commit to OOO_STABLE_1_PORTS. Patch adds: 1) Dan Williams/Patrick Luby locale support 2) 10.2 building support with getpwnam_r() Dan NOTE: tools patch should not be approved yet, on the sal 111902 patch.
Ah hell, approve the tools 100502 patch while you're at it too, it adds 3 MacOS X specific lines. Dan
Hi, Completely MacOSX specific. Looks good, Approved. Kevin
Hi, I should have saiod both are approved. Kevin
sal.OOO_STABLE_1_PORTS.111902.patch tools.OOO_STABLE_1_PORTS.100502.patch Committed to OOO_STABLE_1_PORTS. Removed keyword approval_pending Added keywork merge_pending Dan
Tracking more up-to-date changes to this issue over in Issue 8361
Fixed in ports.
close issue.