[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 |
Hi.
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?
Thanks!
Arnold
-----------------------------------------------------
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,
n->mpg_numbr);
+ /*
+ * 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,
n->mpg_numbr);
else if (is_mpg_integer(n))
mpfr_sprintf(str, "%Zd", n->mpg_i);
else