RE: [Linux-ia64] libgmp3 problem on IA64 (fwd)

[David T. Ashley]

Hi,

I cannot comment on the best way to find and eradicate this bug.  However I
will say this.  Do not immediately assume that the bug is in the GMP.  It is
also possible that:

a)The caller is making mistakes (failing to allocate variables, etc.)

b)Something is amiss with memory management in the O/S or the 'C' library.

c)The compiler is buggy.

In other words, don't narrow the scope of the investigation quite yet.

That said, I have more to say about the GMP ...

I hope everyone grants me the artistic license to use the f-word once and
only once, for effect.  Here goes ...

That fucking GMP code needs a haircut.

I wanted to use the GMP code for large integer arithmetic under Microsoft
Visual C++.  I didn't want to use it in the form provided, because after a
look through it, here is what caught my eye:

a)The code is inconsistent in the naming conventions.  It is normal accepted
practice to prefix all macros and such with the same string to prevent name
collisions.  Lots of the macros and constants don't do this, even though
they are publicly visible.

b)The code contains tabs.  That is prohibited by over half of all coding
standards in the world.

c)The code is incompletely documented.  The end result of this is that when
I "ported" the code, I had to reverse engineer and document a lot of the
functions.  It was an educational experience, but one I did not need to
have.

d)The code is incompletely "assert()"ed.  When I redid a lot of it, I
trapped the function interfaces heavily, which is my standard practice.

e)For anyone who wants to change the code, the process is a bit clumsy.  It
looks like the practice is to e-mail someone the update.  That is OK, but
there should be something better.  Can this be moved to Source Forge?

f)Why in the hell is every function in its own source file?  What is that
crap all about?  How about maybe four or five source files?  If library
efficiency is an issue (such as a linker can't pluck out just one function
unless they are compiled separately), then put all the crap in one source
file and preprocessor it for the 100+ compilations.  Man, there are too many
source files!

g)The macros!!!! Crap man, that is macro hell!  I understand that this is
the best way to do things for efficiency, but man those macros are complex.
In my port, I replaced them with functions and swallowed the efficiency hit.

I removed everything from my "port" that I didn't understand.  If my code
does the segfault/general protection fault kind of thing, I will find it
immediately.

I'm grateful for the GNU MP because it saved me a lot of design time when I
"ported" it--the GNU design for integers is better than my first crack would
have been--using the "size" to hold both the number of limbs and the sign is
brilliant.  Many of the things in the code are brilliant, including the
algorithms.

But, man, that code is a rat's nest and is out of control!

My German is rusty, but that code is true "Saustall" code. It is technically
brilliant, but needs a haircut and a shower and a shave.  Man, it smells
bad.

Dave.

-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of
Duraid Madina
Sent: Wednesday, July 25, 2001 7:40 PM
To: address@hidden
Subject: [Linux-ia64] libgmp3 problem on IA64 (fwd)



Anyone have any comments on this?


        Duraid


----- Forwarded message from Eric Gillespie, Jr. -----

>From address@hidden  Thu Jul 26 09:35:01 2001
Delivered-To: address@hidden
From: "Eric Gillespie, Jr." <address@hidden>
To: address@hidden, address@hidden
Message-ID: <address@hidden>
Mail-Followup-To: address@hidden, address@hidden
References: <address@hidden>
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <address@hidden>; from address@hidden on
Mon, Jul 23, 2001 at 12:40:59AM -0700
Subject: [Linux-ia64] libgmp3 problem on IA64
Sender: address@hidden
Errors-To: address@hidden
X-BeenThere: address@hidden
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <http://lists.linuxia64.org/lists/listinfo/linux-ia64>,
        <mailto:address@hidden>
List-Id: Linux Kernel Discussions on the IA-64 Platform
<linux-ia64.linuxia64.org>
List-Unsubscribe: <http://lists.linuxia64.org/lists/listinfo/linux-ia64>,
        <mailto:address@hidden>
List-Archive: <http://lists.linuxia64.org/archives//linux-ia64/>
Date: Wed, 25 Jul 2001 18:29:26 -0500

For the past couple days i have been investigating an odd segfault in
Sawfish.  For some reason, some people were not seeing it, but once it
starts, it is perfectly reproducable, even after eliminating any state
Sawfish saves (Unix domain socket, configuration files, etc.).

The crash only occurs when using session management; it doesn't matter
if you use xsm or gnome-session.  I know the problem is in GMP (the
GNU MultiPrecision library), but i think i'm in over my head at this
point.  Can anyone help?

I've tracked the crash down to the rep_print_number_to_string function
in librep-0.14/src (rep is the extension language used by Sawfish),
show below.  More debugging later on showed me that the crash happens
in libgmp3-3.1.1/mpn/get_str.c, at the very end of mpn_get_str(),
right where you'll find this crap:

while (s != str)
  *--s = 0;

Anyway, here's the tail end of one of my gdb sessions.

(gdb) break numbers.c:2773
Breakpoint 1 at 0x20000000000c3530: file numbers.c, line 2773.
(gdb) cont
Continuing.

Breakpoint 1, Fnumber_to_string (z=3984315712182462, radix=146)
    at numbers.c:2773
2773        out = rep_print_number_to_string (z, rep_INT (radix), -1);
(gdb) step
rep_print_number_to_string (obj=3984315712182462, radix=36, prec=-1)
    at numbers.c:1091
1091        char *out = 0;
(gdb) next
1093        if (!rep_NUMERICP (obj))
(gdb)
1101            if (radix == 10)
(gdb)
1103            else if (radix == 16)
(gdb)
1105            else if (radix == 8)
(gdb)
1110                obj = promote_to (obj, rep_NUMBER_BIGNUM);
(gdb)
1111                goto do_bignum;
(gdb)
1127            out = mpz_get_str (0, radix, rep_NUMBER(obj,z));
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x20000000002dad51 in __gmpn_get_str () from /usr/lib/libgmp.so.3
(gdb)
Single stepping until exit from function __gmpn_get_str,
which has no line number information.

--
Eric Gillespie, Jr. <*> address@hidden
Software Developer
Progeny Linux Systems - http://progeny.com
"I don't know what a Sawfish Window Manager is."

_______________________________________________
Linux-IA64 mailing list
address@hidden
http://lists.linuxia64.org/lists/listinfo/linux-ia64

----- End of forwarded message from Eric Gillespie, Jr. -----

_______________________________________________
Bug-gmp mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/bug-gmp