Apache OpenOffice (AOO) Bugzilla – Issue 18188
Crash in lingucomponent/.../sspellimp.cxx getLocales
Last modified: 2013-02-24 20:34:08 UTC
This bug is filed as result of a crash report. There was a crash in : void SAL_CALL rtl_uString_newFromAscii( rtl_uString** ppThis, : const sal_Char* pCharStr ) : from file rtl/source/ustring.c The stack is : sal3!rtl_uString_newFromAscii+0xc : spell645mi!rtl::OUString::createFromAscii+0x18 : spell645mi!SpellChecker::getLocales+0x353 : lng645mi!LngSvcMgr::GetAvailableSpellSvcs_Impl+0x271 : lng645mi!LngSvcMgr::getAvailableServices+0xa0 The source code is : //first add the user dictionaries : for (i = 0; i < numusr; i++) { : Locale nLoc( A2OU(updict->lang), A2OU(updict->region), OUString() ); newloc = 1; .... : } The crash happens in the line where the Locale is created. The systemn was a WIN32 platform. The e-mail of the use is: ddardenne@europarl.eu.int According to an attachement from the crash report the dictionary.list was change like this: DICT da DK da_DK DICT de DE de_DE DICT el GR el_GR DICT en GB en_GB DICT es ES es_ES DICT fr FR fr FR <<<<< DICT it IT it_IT DICT nl NL nl_NL DICT pl PL pl_PL DICT pt PT pt_PT DICT sv SE sv_SE There is an "_" missing in the line for the French entry. Probably this resulted in the crash. Seems the parsing of the dictionary.list should be more secure against writing errors. Thats about all the crash report provided. If you need any further information you probably have to contact the original user.
Set target.
Hi, Thanks for the bug report and backtrace info. Unfortunately, the missing underscore in the name of the dictioanry should not be a problem here (the file fr.aff and fr.dic will be looked for and not found and no segfault should happen). Since the first two fields after the DICT determine explictly the lang and region both of those values look fine in the dictionary.lst I would bet instead the user has a second dictionary.lst file someplace in user/wordbook/ that he/she is bad entries in. The code here is for parsing the info in user/wordbook/ and not the main one in share/dict/ooo/. I bet this came from an old dictionary.lst not properly removed when an update or reinstall was done. Please ask the user to attach both his "dictionary.lst" files (any found in user/wordbook/ and any found in /share/dict/ooo) and provide directory listings for all files in share/dict/ooo/ and user/wordbook/. So we can see what is actually casuing the segfault in this case. The code below should be robust to the error you showed below. But you are right, in general I need to make the parsing of dictionary.lst more robust against poor user input. Kevin
Created attachment 8449 [details] /share/dict/ooo/dictionary.lst
Created attachment 8450 [details] user/wordbook/ /dictionary.lst
TL->Kevin: Please have a look again.
Hi Thomas, I did. Unfortunately, the mistake in the user/wordbook/dictionary.lst should NOT have created the problem he got. The question I have is exactly what files are in his user/wordbook directory? One possible problem may be he reports these dictionaries but does not actually have the dictionary files in the right places. Could the reporter please post a directory listing showing file sizes for all files in user/wordbook/ and share/dict/ooo/ just so that I can check they correspond to the actual dictionary.lst file entries. The only long term solution (post OOo 1.1.0) is to try to make the parsing code more robust which is on my to-do list for lingucomponent. I really don't have any other ideas and this one seems to be a one-off bug (have there been any other crash-reports stacktrces back to getLocales?). So I am leaving this targeted as 1.1.1 when I get a chance to make the parse code more robust unless you/Hamburg have recived a lot of crash reports indicating something sytematic and not something specific. Is that okay? Kevin
No there are no other crashreports. > So I am leaving this targeted as 1.1.1 when I get a chance > to make the parse code more robust unless you/Hamburg have > recived a lot of crash reports indicating something sytematic > and not something specific. That's OK with me.
Hi, So I will change this to an enhancement request to make the dictionary parsing more robust targeted for the 1.1.X series. Thanks, Kevin
Hi Thomas, Okay I found a bug here when there were too many pieces of information provided as in the example case. I have no changed the code to handle that and to echo corrupted lines to stderr so that console programs / loggers can detect the error and the user can correct it (needed since this is a user edited file). I have now committed this fix to OOo 1.1.1 and tested it with the offending example in this issue and all is now fine. I am resolving this as fixed and I will close it once OOo 1.1.1 has been released and the fix is verified. Thanks for the stacktraces! Kevin
close issue.