[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gawk] incorrect checksum for freed object ... Abort trap: 6 ...

From: Aharon Robbins
Subject: Re: [bug-gawk] incorrect checksum for freed object ... Abort trap: 6 ... fatal error: internal error: segfault
Date: Wed, 11 Mar 2015 20:38:10 +0200
User-agent: Heirloom mailx 12.5 6/20/10


Thanks for the report.

> Date: Wed, 11 Mar 2015 09:01:43 +0100
> From: Hermann Peifer <address@hidden>
> To: "address@hidden" <address@hidden>
> Subject: [bug-gawk] incorrect checksum for freed object ... Abort trap: 6
>  ... fatal error: internal error: segfault
> Hi,
> I am getting the below errors very occasionally, but even when using the 
> -o switch, i.e. not processing any data at all. The "incorrect checksum 
> for freed object" error occurs perhaps in 1 out of 100 script runs, the 
> segfault error even less often.
> I am not sure if these errors are interrelated, they seem to go away 
> when either dropping -o/-p or -M. I'll send the script code and a Mac OS 
> X crash report in a private mail. Hope this is OK.
> Wild guess based the crash report: libgmp.10.dylib and __gmp_doprnt are 
> mentioned there, so maybe this is not a GAWK issue in the first place.
> Hermann

Valgrind shows a problem under Linux.  The patch below fixes it, and also
makes the profiled/pretty-printed output look normal when using -M. Can
you try it out before I push it? (Save the patch to a file, then use

        patch -p1 < the-file

and rebuild.)

The patch is relative to gawk-4.1-stable but should work on master as well.

May I add your test program and data file to the test suite?


diff --git a/profile.c b/profile.c
index 316ba39..7581cfb 100644
--- a/profile.c
+++ b/profile.c
@@ -1305,10 +1305,20 @@ pp_number(NODE *n)
 #define PP_PRECISION 6
        char *str;
-       emalloc(str, char *, PP_PRECISION + 10, "pp_number");
+       /*
+        * 3/2015: This was + 10. Making it + 20 avoids some issues with
+        * MPFR overwriting past the end of the buffer. But it's a mystery
+        * why we're sizing the buffer this way in the first place.
+        */
+       emalloc(str, char *, PP_PRECISION + 20, "pp_number");
 #ifdef HAVE_MPFR
        if (is_mpg_float(n))
-               mpfr_sprintf(str, "%0.*R*g", PP_PRECISION, ROUND_MODE, 
+               /*
+                * 3/2015: Format string used to be "%0.*R*g". That padded
+                * with leading zeros. But it doesn't do that for regular
+                * numbers in the non-MPFR case.
+                */
+               mpfr_sprintf(str, "%.*R*g", PP_PRECISION, ROUND_MODE, 
        else if (is_mpg_integer(n))
                mpfr_sprintf(str, "%Zd", n->mpg_i);

reply via email to

[Prev in Thread] Current Thread [Next in Thread]