GNOME Bugzilla – Bug 358337
crash in Calculator: 1. Selected Oriya from t...
Last modified: 2006-10-01 16:24:03 UTC
What were you doing when the application crashed? 1. Selected Oriya from the language selection while logging in gdm. 2. Tried to open calculator from accessories and it opened the bug-buddy directly. Expected Result: Should operate properly in the current locale. Distribution: Fedora Core release 5.92 (FC6 Test3) Gnome Release: 2.16.0 2006-09-04 (Red Hat, Inc) BugBuddy Version: 2.16.0 Memory status: size: 81907712 vsize: 0 resident: 81907712 share: 0 rss: 11522048 rss_rlim: 0 CPU usage: start_time: 1159547416 rtime: 0 utime: 27 stime: 0 cutime:21 cstime: 0 timeout: 6 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gcalctool' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208727328 (LWP 2536)] (no debugging symbols found) 0xb7f6f402 in __kernel_vsyscall ()
+ Trace 73589
Thread 1 (Thread -1208727328 (LWP 2536))
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Does this happen always?
I just tried adding the Oriya translato, Gora Mohanty, to the bug cc: but s/he doesn't seem to be around any more. The last time this translation was updated according to the .../po/ChangeLog file was: 2004-10-26 Gora Mohanty <gmohanty@cvs.gnome.org> * or.po: Updated Oriya translation: fixed last 2 fuzzies That's almost two years ago. I would imaging that this file is very much out of date. What should be done in case like this? I'll send an email to the GNOME i18n folks to ask.
I do not have an installation of gnome 2.16 in order to check this at the moment, and the attached trace is not very useful because of the lack of symbols. I just checked with gnome 2.14, and gcalctool works fine, and shows a properly localised interface under the Oriya locale. I will check this on 2.16, but as I will be out of India till the 11th of October, that can only be done when I get back. One possibility is that the user has an improper Oriya locale installed. There is one available on the Rebati site, at http://oriya.sarovar.org/download/or_IN.gz and instructions for installing it are at http://oriya.sarovar.org/docs/getting_started/node16.html . Unfortunately, this locale has not been submitted to glibc, as I could not figure out where to do that. Do other applications work, and show proper Oriya interfaces under the same Oriya locale?
An application should NEVER crash due to incomplete translations. I don't see why the translations are related to the crash. Untranslated messages just show up in English, so there should not be any problem other than a partly translated interface.
Thanks Gora/Wouter. sbehera@redhat.com, could you try Gora's instructions and see if that improves things for you?
Hi Rich Changing the locale didn't solve the problem. However, as you have noticed earlier the file has not been revised for quite a long time. Hence, it may have lead the problem. I have updated the translation and the same has been committed to the CVS. The new revision is: 1.18.2.1 I think there were some fatal errors in the .po file may be because of the fuzzy. If that's the reason then it should work fine now. Kindly check the same. Regards, Subhransu
Dear Subhransu, What do you mean by "there were some fatal errors in the .po file"? I check out any .po files submitted by me for correctness, and double- checked just now that the earlier version indeed compiled correctly into a .mo file. Anyway, invalid .po files should be caught in the build process. In any case, as Wouter notes, incorrect .po files should never crash the application. I was thinking that this might be some obscure bug in glibc exercised by an incorrect Oriya locale. However, even that was quite unlikely, and is ruled out by your changing the locale. How are you testing gcalctool under GNOME 2.16? Did you build it yourself? Using jhbuild? Does that version of gcalctool work under the en_US locale? Do you have access to the 2.14 branch of gcalctool? Does that work for you, under the en_US locale, and under the Oriya locale? Do other GNOME 2.16 applications work under the Oriya locale? Please let us know the answer to these questions, and, if possible, recompile GNOME 2.16 with debuggingh enabled, and send a new stack trace. Thanks. Regards, Gora
Created attachment 73734 [details] [review] a patch This is due to sloppy string handling all over the place in gcalctool. I have attached a patch which fixes 2 such places and allows gcalctool to come up in or_IN. There are certainly more places where it can crash.
Thanks Matthias. I've checked your changes into CVS HEAD and bumped the version number in configure.in to 5.9.2. Closing as FIXED. I've also open bug #358337 against gcalctool as a placeholder to remind me to go over the gcalctool code and fixup the other occurances of sloppy string handling.
Thanks All :-)