GNOME Bugzilla – Bug 520474
Calculator uses 06 in place of decimal
Last modified: 2008-03-07 18:17:15 UTC
Please describe the problem: This bug has been reported under ubuntu with the latest version available (5.21.92). The ubuntu bug can be found here : https://bugs.edge.launchpad.net/ubuntu/+source/gcalctool/+bug/198250 Steps to reproduce: 1. -(5)/4 Actual results: -1625, and afterward all answers with decimals will be wrong. Expected results: -1,25 Does this happen every time? YES Other information: This bug seems to be a regression from 5.20.2, since it was working at that revision.
Confirmed. This is a major bug indeed. Sami, can you have a look at it as soon as you can please? It's critical we get a fix for this before GNOME 2.22.0 (i.e. next Monday). Thanks. PS: I think the Summary is wrong (and confusing), but I'm not going to change it until it's been properly evaluated
If you want any additional information, just let me know...
I just been playing with this a bit more. If I just startup gcalctool, with decimal numeric base and scientific mode and enter: 5 / 4 <Return> I get the answer of "1.25". That's good. If I just startup gcalctool, with decimal numeric base and scientific mode and enter: ( 5 ) / 4 <Return> I get "Malformed expression" (see separate bug #520525 which I just filed -- although it all seems to be related). If I just startup gcalctool, with decimal numeric base and scientific mode and enter: - ( 5 ) / 4 <Return> I get "-1625". After that, even after doing a clear, something doing 5 /4 / <Return> now gives a bogus answer of "1625".
Actually, this may not be a problem in the calculation parser. I did the following: I started up gcalctool, with arithmetic precedence, with decimal numeric base and scientific mode and entered: - ( 5 ) / 4 <Return> I got "-1625". I then changed to left-to-right precedence mode and entered: 5 /4 / <Return> and got the bogus answer of "1625". But I'd also added an fprintf statement in the do_calc() routine in functions.c: $ svn diff functions.c Index: functions.c =================================================================== --- functions.c (revision 1991) +++ functions.c (working copy) @@ -689,6 +689,7 @@ case KEY_DIVIDE: mpdiv(v->MPresult, v->MPdisp_val, v->MPresult); + fprintf(stderr, "do_calc: KEY_DIVIDE: result: %s\n", make_number(v->MPresult, v->base, FALSE)); break; case KEY_MODULUS_DIVIDE: This had printed out: do_calc: KEY_DIVIDE: result: 1.25 So maybe the Summary line isn't incorrect after all.
The problem is a memory corruption causing v->radix to be overwritten with the value of "6". In calctool.h, there is: ... char fnum[MAX_DIGITS]; /* Scratchpad for fixed numbers. */ const char *radix; /* Locale specific radix string. */ ... the fnum variable is going beyond its allocated size. Patch to follow.
Created attachment 106629 [details] [review] Patch to hopefully fix the problem. Not committed yet. I need to grovel to the release team to get this approved for committing as we are past the hard freeze. If others could further test this in the meantime, it would be very much appreciated.
I just tried it without the patch on my 64-bit Hardy box and didn't even get the "6". gcalctool just sits there, and this error results: (gcalctool:14609): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed With the patch, I get -1.25 and no error. :-)
Patch approved by the release team for GNOME 2.22 (thanks!). It's been committed to SVN trunk. I'll generate a new gcalctool tarball (v5.22.0) next Monday. I've also opened bug #520769 so that we can fixup all occurrences of where we currently still use strcpy(), and replace them with strncpy(). Closing as FIXED. Thanks for finding and reporting this bug Christophe.
Great ! As a matter of a fact I am not the finder :) just the reporter. once you release 5.22.0, I'll package it for ubuntu (I am subscribed at the gnome-ftp-release list so I'll be warned). Thanks for this quick fix !
*** Bug 521033 has been marked as a duplicate of this bug. ***