I've just tried to reproduce this (with v4.4.20) on my
Solaris GNOME distribution and I'm not able to. Any chance
you could check out a copy of this version of gcalctool
from CVS, compile it with debug on, and give me more debug
information (like exact line number in mpstr where it's
failing) please?

Note, that you would need to check it out with:

cvs co -r gnome-2-8 gcalctool

Oh I'm sorry, I gave you the wrong instructions to reproduce the bug.

You should press twice on (, then Clr, then twice on ).
I didn't try the cvs but I tried a newer version of the program
(gcalctool-4.4.20), but the bug still remained. 

GDB gave this information when I compiled gcalc with -gstabs+:

gdb ./gcalctool
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) run
Starting program: /tmp/gcalctool-4.4.20/gcalctool/gcalctool
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
[New Thread 16384 (LWP 3651)]
/usr/share/themes/Nuvola/gtk-2.0/iconrc:23: Unable to locate image file in
pixmap_path: "stock_stock.svg"
/usr/share/themes/Nuvola/gtk-2.0/iconrc:54: Unable to locate image file in
pixmap_path: "stock_ok.svg"

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3651)]
0x0805cb26 in mpstr (x=0xfffffffc, y=0x806f758) at mp.c:4202
4202        j = x[1];
(gdb)

I saw a little bit on the code and I think that do_clear() isn't doing it's
job properly (just a guess).

Thanks Wictor. Interestingly I still can't get it to
fail on Solaris (v4.4.20) even with the revised instructions
on how to reproduce it. 

Looking at the debug information, x (0xfffffffc) is definitely
bogus. I'll try to puzzle it out. 

Looks like bug #106583 is the same problem. That was
supposedly fixed in v4.2.55. Comment from that bug is:

  The crash was caused by the paren_disp() function in display.c not
  correctly checking for when a Delete character was entered.

Continuing to investigate.

Wictor, there is something you can try if you'd
like to help me debug this.

In the paren_disp() routine in display.c (about line 453),
can you add the following line:

  fprintf(stderr, "paren_disp: c: %d\n", c);

Rebuild and rerun. What I suspect you'll find is that it's
not catching the Delete/Clr character case and is going 
through the wrong part of this routine.

Thanks.

OK, now I think I got something...

I added the line you told me about and the output from it was:

paren_disp: c: 40 <-- First left parenthesis
paren_disp: c: 40 <-- Second left parenthesis
paren_disp: c: 127 <-- Clr
paren_disp: c: 41  <-- First right parenthesis
paren_disp: c: 41  <-- Second right parenthesis
paren_disp: c: 40  <-- ??
paren_disp: c: 40  <-- ??
And then program crashes..

So what I did then was to change the first if statement in the function
from:
    if (c == -1) {         /* Is it a Delete character? */
to:
    if (c == -1 || c == 127) {         /* Is it a Delete character? */

and then the program quits crashing.

Thanks Wictor. Looks like bug #163622 is the same problem.
I'm checking there to see if this one line change will fix that
problem too. If so, then I'll check the chanfe in.

Looks like bug #163633 is fixed with the changes for bug #157277
(which will also fix the "funny character" problem mention above).
Change checked into CVS HEAD. I've bumped the version number in
configure.in to 4.4.22. I plan to generate a new tarball when I'm
sure that the fix to bug #157277 is indeed the fix for bug #163633.

*** Bug 302002 has been marked as a duplicate of this bug. ***