GNOME Bugzilla – Bug 468200
crash in Calculator: Exploring the scientific ...
Last modified: 2008-07-17 08:18:01 UTC
What were you doing when the application crashed? Exploring the sientific calculator. Distribution: Fedora release 7 (Moonshine) Gnome Release: 2.18.3 2007-07-02 (Red Hat, Inc) BugBuddy Version: 2.18.0 System: Linux 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:35:01 EDT 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 10300000 Selinux: Enforcing Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: Fedora Memory status: size: 39079936 vsize: 39079936 resident: 21241856 share: 15925248 rss: 21241856 rss_rlim: 4294967295 CPU usage: start_time: 1187535945 rtime: 1457 utime: 729 stime: 728 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 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 -1208961312 (LWP 2384)] (no debugging symbols found) 0x00df2402 in __kernel_vsyscall ()
+ Trace 156342
Thread 1 (Thread -1208961312 (LWP 2384))
----------- .xsession-errors (16 sec old) --------------------- localuser:talek being added to access control list SESSION_MANAGER=local/fedora:/tmp/.ICE-unix/2126 gcalctool: functions.c:801: do_constant: Assertion `v->current->value[0] <= '9'' failed. --------------------------------------------------
It's not really a crash. It's another of those annoying assertions, that really should just be a message on the gcalctool status bar, rather than aborting the program. It's an error that can be worked around and not be fatal. Sami, could you please rework: static void do_constant() { assert(v->current->value[0] >= '0'); assert(v->current->value[0] <= '9'); ... to be exactly that. Thanks. PS: The workaround is to remove (or sanely edit) ~/.gconf/apps/gcalctool/%gconf.xml so I'm reducing this to "major" severity.
Rich, could you explain why v->current->value[0] is bigger than 9? It would seem to me that gcalctool is trying to access a constant outside the range. I see only constants from C0 to C9 in my version of gcalctool.
I have no idea why v->current->value[0] is greater than 9, but for whatever reason it should abruptly terminate the application when a simple warning to the user would suffice.
This is "index out of range" type of bug. Now that we don't know what is causing this we don't know how serious this is. I am assuming the worst. The cause might be even memory corruption bug. Thus, in my oppinion, we have no control over what happens if execution continues even if these asserts fail. Rich, are you able to reproduce this bug?
No. My guess is that the submitter has entries in his %gconf.xml file that don't match up with the way gcalctool is parsing it. I still think it's acceptable to put a warning in. Note that gcalctool is now a Gtk+ application for GNOME 2.19/2.20. That means that when it crashes (or aborts like in this case), it will no longer call bug-buddy to send off an error report. This means that if the user started gcalctool from one of the gnome panel menus (Applications->Accessories->Calculator), then they will not see the assertions. They will just think the calculator has crashed. If you won't change the assertion to be just a status bar warning, then instead of asserting and just exiting, you will need to put up a graphical dialog explaining why you think it's necessary to terminate the application. I see you have fifty places in the gcalctool code where such assertions could be triggered. I suggest that these now need to be handled in a similar way now. It's too late for GNOME 2.20, but it would be nice if this was one of the first changes in the GNOME 2.21/2.22 cycle.
I like the idea about graphical dialog. The dialog could contain: - Explanation to user what is happening. - Details about the error (same information than the assert prints). Also gcalctool version would be nice to print. - Suggestion to user that he/she should report the error. - http link to gcalctool bugzilla. I think the asserts can be easily converted to the dialog. How does this sound?
Sounds very good. Don't forget that translators will have to translate all the new strings. I suggest a boiler-plate message, something like: An unexpected error has occured < include untranslated > < message from assert > < include stack trace > This is gcalctool version X.Y.Z Please report this problem to: http://bugzilla.gnome.org/enter_bug.cgi?product=gcalctool [ Cancel ] [ OK ] That will keep the number of strings that have to be translated to a minimum. I suggest putting the assert message and the stack trace in a scrollable text area, which will make it easy to cut and paste into the new bug report.
Sounds good. I take this under work.
Adjusting priority/severity to reflect the true nature of this problem.
Closing as this is not being reproduced. The bug was an assert for an invalid value so there was probably memory corruption at the time. There have been significant changes to the structure since that makes this almost certainly unreproducable.