Created attachment 22129 [details]
A fix (I think), albeit a bad one.

I think the problem is that the initial constant
strings are being put in read-only memory either 
by gcc (or because of the way that x86 arch is
designed). I tested this with the Sun compiler
on a Solaris SPARC machine which didn't exhibit 
a problem.

I've attach a small diff. Could you try it and 
see if it solves the problem please? It isn't 
a great fix as it will leak memory. If this works 
for you, I'll try to devise a better fix.

Thanks.

Created attachment 22130 [details]
A better fix.

Here's a better fix that doesn't leak memory.

Created attachment 22137 [details]
An even betterer fix (with locale support ;-)

Last patch checked into CVS HEAD. Fixed in v4.3.29.
Thanks again for the interactive debugging on IRC!

this bug also existed on a quite up to date gentoo x86 system

4.3.29 fixed the start-up crash too for us

Ohh. Well it's hard to fix bugs that I don't know
about ;-), so if you have any others like this please
file 'em in Bugzilla. Thanks.

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

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

I have sth like this bug again in 4.3.31.
I get a SIGSEG when starting.
I'll attach a screenshot of ddd on this position which should explain
the problem.
I use gcc 3.2.2.

Created attachment 22806 [details]
Screenshot of debug session

What a mess - this function remove_tsep!

When this str is a constant string you write in read-only memory with
this *dstp++ = *srcp++. Well, you can simply work on a second string
and hope, that the constants are OK, but what a mess.

The following works for me:
diff display.c.orig display.c:
<     char *dstp = str;
---
>     char *dstp,*dstpptr; // = str;
90c90
< 
---
>     dstp=dstpptr=strdup(str);
101a102,103
>     if (strcmp(srcp,dstp)!=0) { memcpy(srcp,dstp,strlen(srcp)); }
>     free(dstpptr);

Yes, remove_tsep() is a mess because it really
shouldn't have to care about whether the character
string is in read-only memory or not. I blame
the compiler. I certain don't have to jump through
hoops with the Sun compiler. 

Also the initial constant values shouldn't have any 
thousand separators in them, so you might be fixing the
wrong problem here and this is another variant of
bug #130282. Perhaps we should determine if you have
this problem if you unset the LANG variable.

Anyway...

A far better "fix", is to do the string duplication
in init_vars() in get.c. Something like:

    MPstr_to_num(strdup("0.621"), DEC, 
                 v->MPcon_vals[0]);  /* kms/hr <=> miles/hr. */
    MPstr_to_num(strdup("1.4142135623"), DEC, 
                 v->MPcon_vals[1]);  /* square root of 2 */        
    MPstr_to_num("2.7182818284", DEC, 
                 v->MPcon_vals[2]);  /* e */
    MPstr_to_num(strdup("3.1415926535"), DEC, 
                 v->MPcon_vals[3]);  /* pi */
    MPstr_to_num(strdup("0.3937007"),    DEC, 
                 v->MPcon_vals[4]);  /* cms <=> inch. */
    MPstr_to_num(strdup("57.295779513"), DEC, 
                 v->MPcon_vals[5]);  /* degrees/radian. */
    MPstr_to_num(strdup("1048576.0"),    DEC, 
                 v->MPcon_vals[6]);  /* 2 ^ 20. */
    MPstr_to_num(strdup("0.0353"), DEC, 
                 v->MPcon_vals[7]);  /* grams <=> ounce. */
    MPstr_to_num(strdup("0.948"),  DEC, 
                 v->MPcon_vals[8]);  /* Kjoules <=> BTU's. */
    MPstr_to_num(strdup("0.0610"), DEC, 
                 v->MPcon_vals[9]);  /* cms3 <=> inches3. */

We could even write a little macro for it:

#define INIT_CONSTANT(n, val) \
              MPstr_to_num(strdup(val), DEC, v->MPcon_vals[n]);

Then those ten lines become something like:

    INIT_CONSTANT(0, "0.621");   /* kms/hr <=> miles/hr. */
    ...

Much cleaner.

Georg, if unset LANG doesn't solve your problem, can you 
determine if this approach fixes the problem for you 
(with the current implementation of remove_tsep - i.e. 
without your suggested fix)?

Adding Georg to the CC: line of this bug
so he can see my comments to the bug he
reopened. So why doesn't Bugzilla automatically
do that?

You're right, LC_ALL=C fixes the problem. Nevertheless I think it's
illegal programming.
Applying the patch of this other bug also fixes the problem!

Created attachment 22823 [details] [review]
Proposed patch

Setting LC_ALL only sometimes fixes this error.

Your proposed fix works. I've uploaded the patch in this bug report as 
an attachment (id=22823).

Thanks Georg. Actually thinking about this some
more, there is still a problem here. The constant
values in init_vars() have "." hard-wired as the
radix separator. That's bogus. Those initial
values will need to be constructed (appended
together) using whatever is returned by get_radix() 
in get.c for the equivalent of ".".

What might be better here is to actually have them as
localizable strings.

Adding Christian to the CC: list for his take on this.

 

Let me just mention that the strdup isn't freed again in the proposed
patch!

Setting some bits, we want to track this and make sure it is fixed 
for 2.6.0. Thanks for all the work, guys.

Danilo, Christian, what are your opinions?

Bug #130282 is related to this. Using the latest attachment
there, there is no need to localise the initial constant
strings. That just leaves the crash because those strings 
are in read-only memory on some systems. The latest attachment
from Georg will fix that (albeit the strings aren't freed which 
I can live with ;-)).

I'll check in this fix tomorrow. Thanks to all that have been
involved with this.

Well, I don't like unfree'd memory:
Why don't you use sth. like 
#define INIT_CONSTANT(n, val) \
              MPstr_to_num(a=strdup(val), DEC, v->MPcon_vals[n]); \
              free(a);

Good point. We should probably use the glib calls
too. I'll adjust accordingly on Monday. Thanks.

Created attachment 22943 [details]
Final version of the proposed patch (hopefully ;-)

Changes checked into CVS HEAD. Fixed (hopefully
for the last time ;-) in v4.3.32.

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

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

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