GNOME Bugzilla – Bug 305467
gcalctool crashes when given an invalid user function number.
Last modified: 2005-05-26 17:25:12 UTC
Steps to reproduce: 1. start gcalctool 2. start to play with your keyboard and input as many letters as you can 3. crash Stack trace: (gdb) r Starting program: /home/peter/1-gcalc/gcalctool-5.5.42/gcalctool/gcalctool [Thread debugging using libthread_db enabled] [New Thread -1224296768 (LWP 14185)] gcalctool: functions.c:900: do_function: Assertion `v->current->value[0] <= '9'' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1224296768 (LWP 14185)] 0xffffe410 in __kernel_vsyscall () (gdb) (gdb) bt
+ Trace 60179
Other information: I've encounter this bug when I was writing something and using gcalctool. BTW. After this crash behaviour of gcalctool changed. If before I could see something like 4+3*6 now it's works like an ordinary calculator. I can see only current number. Is there any possibility to revert this behaviour? And of course, it's good idea to have menu item with the possibility to choose behavior.
What version of gcalctool are you running? Do a Help->About from the menu bar to determine this. If it's < 5.6.14, could you try the latest by downloading it from: http://ftp.gnome.org/pub/GNOME/sources/gcalctool/5.6/ It looks like you were in "Arithmetic Precedence" mode. See if the View->Use Arithmetic Precedence menu item is checked. Does the behaviour (i.e. crash) happen in both modes (When "Use Arithmetic Precedence" is checked and not checked)?
Okay, I've worked out what's going on now. The key is: > functions.c:900: do_function: Assertion `v->current->value[0] <= '9'' failed. It's failing with you entering a user defined function number that's not in the range 0-9. Now there was a little bit of work done in the 5.6.X series of gcalctool thatfixes this. See bug #172704. That should be fixed in the 5.6.14 version I pointed you at above. I'm adjusting the summary for this bug to reflect what's really going on. Speed has nothing to do with it.
Created attachment 46888 [details] Fix crash with dismissal via mouse click There was also a problem if the user dismissed the function menu with a mouse click rather than via the Esc key. This patch addresses that problem.
Changes checked into CVS HEAD. Bumped the version number in configure.in to 5.6.15.
Thank you for your attention. I did not manage to reproduce bug with "Use Arithmetic Precedence" is checked. So I assume that I'm not in this mode. I had 5.5.42 version. Today I've tryed 5.6.14 version. I can reproduce bug. And first I reproduced the bug with the previous backtrace (Well. Actually I did not manage to see bt, as my keyboard stay locked after gcalctool: functions.c:834: do_function: Assertion `v->current->value[0] <= '9'' failed.). Now I have another bt: (gdb) r Starting program: /home/peter/1-gcalc/gcalctool-5.6.14/gcalctool/gcalctool [Thread debugging using libthread_db enabled] [New Thread -1224296768 (LWP 14987)] (gcalctool:14987): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1224296768 (LWP 14987)] show_menu_for_button (widget=0x0, event=0x82c90cc) at gtk.c:2865 2865 menu = create_menu(n->mtype, n); (gdb) (gdb) BT
+ Trace 60211
As you can see, now it's Segmentation fault. May this is not gcalctool, but gtk problem? But I don't know how to check... BTW. I have gtk+-2.6.7 installed.
Thanks for your followup. Reopening to investigate the new problem.
Peter, Could I ask you to do a couple things please. Could you take the 5.6.14 version and apply the patch in the attachment to this bug and see if you still get the crash. If you do, could you print out the values of "n" and "n->type" please? As you are getting: (gcalctool:14987): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed and 178 levels of stack trace, it looks like there may be a memory corruption occuring here. Also, is it random keyboard characters you are entering or is there a reproducable test case I can use here? If it's the former, perhaps you could add the following line just before the first if statement in the kframe_key_press_cb() routine in gtk.c (about line 1836): fprintf(stderr, "key press: event->keyval: %d event->state: %d\n", event->keyval, event->state); and recompile and rerun gcalctool and sent me the output that it generates. Thanks.
I've used your patch, and now I can not reproduce this bug. So it seems that this patch fixes not only mouse behaviour. I'm closing bug. BTW. Why gnome-2.10 uses 5.5.42 so may be it's good idea to backport this patch? In any way, thank you for your work.
> So it seems that this patch fixes not only mouse behaviour. Good. Thanks for trying it out. > may be it's good idea to backport this patch? Indeed. I'll do that now.
Ack! This fix also depends upon the changes for bug #172704 which includes string changes, so I won't be able to backport it after all. Roll on GNOME 2.12.