Thread: NetBSD mac68k crashing on union regression test

Hi,

My buildfarm member, osprey, has been crashing on the union regression
test on CVS tip since after march 11th with a segmentation fault.
See the backtrace further down.

The crash occurs in pg_sprintf,  work on which has been done beginning
march 11th....

I'm not sure I'm reading the trace correctly, but I find odd that it
seems to crash when trying to output the value
"-5.7430974560366591e+240", but in the expected result of the union
test, this value does not seem to be present.

Does someone see where the problem might be ?

The type argument to fmtfloat is odd (char 0). It should be one of
'eEfgG', no ?

Regards,

Rémi Zara

#0  0x0446f192 in __bt_search () from /usr/lib/libc.so.12
#1  0x0446f6de in __bt_search () from /usr/lib/libc.so.12
#2  0x0447110e in __dtoa () from /usr/lib/libc.so.12
#3  0x0446d4c0 in vfprintf_unlocked () from /usr/lib/libc.so.12
#4  0x0446d1ac in vfprintf_unlocked () from /usr/lib/libc.so.12
#5  0x0446138c in sprintf () from /usr/lib/libc.so.12
#6  0x001b814c in fmtfloat (value=-5.7430974560366591e+240, type=0
'\0', forcesign=0, leftjust=0, minlen=0, zpad=0, precision=15,
pointflag=1, end=0xffffb4c7 "\r????",     output=0xffffa478) at
snprintf.c:671
#7  0x001b79a0 in dopr (buffer=0xffffa4c8 "", format=0x22eab7 ".*g",
args=0xffffb4e4 "", end=0xffffb4c7 "\r????") at snprintf.c:561
#8  0x001b75fe in pg_vsnprintf (str=0xffffa4c8 "", count=4096,
fmt=0x22eab6 "%.*g", args=0xffffb4d8 "") at snprintf.c:83
#9  0x001b7660 in pg_sprintf (str=0x303b88 '\177' <repeats 129 times>,
"~", '\177' <repeats 70 times>..., fmt=0x22eab6 "%.*g") at
snprintf.c:109
#10 0x00151f72 in float8out (fcinfo=0x4492994) at float.c:545
#11 0x0019fc42 in FunctionCall3 (flinfo=0x4492994, arg1=72168376,
arg2=0, arg3=4294967295) at fmgr.c:1186
#12 0x00030a46 in printtup (slot=0x3030e0, self=0x2fd740) at
printtup.c:341
#13 0x000cbbd4 in ExecSelect (slot=0x3030e0, dest=0x2fd740,
estate=0x303020) at execMain.c:1312
#14 0x000cb918 in ExecutePlan (estate=0x303020, planstate=0x3031c0,
operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection,
dest=0x2fd740) at execMain.c:1213
#15 0x000cabce in ExecutorRun (queryDesc=0x2cdcb0,
direction=ForwardScanDirection, count=0) at execMain.c:228
#16 0x0013e34c in PortalRunSelect (portal=0x301020, forward=1 '\001',
count=0, dest=0x2fd740) at pquery.c:746
#17 0x0013e0d2 in PortalRun (portal=0x301020, count=2147483647,
dest=0x2fd740, altdest=0x2fd740, completionTag=0xffffb9a8 "") at
pquery.c:561
#18 0x0013a9f4 in exec_simple_query (query_string=0x2f2020 "SELECT f1
AS ten FROM FLOAT8_TBL\nUNION ALL\nSELECT f1 FROM FLOAT8_TBL;") at
postgres.c:934
#19 0x0013cbc4 in PostgresMain (argc=4, argv=0x289400,
username=0x289260 "rzara") at postgres.c:3014
#20 0x0011a90c in BackendRun (port=0x292200) at postmaster.c:2787
#21 0x0011a20a in BackendStartup (port=0x292200) at postmaster.c:2427
#22 0x001189e8 in ServerLoop () at postmaster.c:1208
#23 0x00118338 in PostmasterMain (argc=6, argv=0xffffc50c) at
postmaster.c:917#24 0x000e661e in main (argc=6, argv=0xffffc50c) at
main.c:268


--
Rémi Zara
http://www.remi-zara.net/

Rémi Zara <remi_zara@mac.com> writes:
> The crash occurs in pg_sprintf,  work on which has been done beginning
> march 11th....

Offhand I'd bet it's overrunning its malloc'd arrays because the loop at
the top doesn't count "*" as needing a fmtpos position.
        regards, tom lane

Hi,

With the following patch, the crash still occurs in the same way. But
it does seem, reading the code, that it still may be necessary.

Re-reading the backtrace, here is another strange thing:
[...]
#7  0x001b79a0 in dopr (buffer=0xffffa4f8 "", format=0x22eab7 ".*g",
args=0xffffb514 "", end=0xffffb4f7 "\r???$") at snprintf.c:561
#8  0x001b75fe in pg_vsnprintf (str=0xffffa4f8 "", count=4096,
fmt=0x22eab6 "%.*g", args=0xffffb508 "") at snprintf.c:83
[...]

Note how the format loses the '%', for no apparent reason.

I see that pg_vsnprintf is defined differently than pg_snprintf,
pg_sprintf, pg_fprintf and pg_printf concerning va_list.
Is there a reason for that ?


RCS file: /projects/cvsroot/pgsql/src/port/snprintf.c,v
retrieving revision 1.26
diff -u -r1.26 snprintf.c
--- snprintf.c  20 Mar 2005 13:54:53 -0000      1.26
+++ snprintf.c  12 Apr 2005 06:08:02 -0000
@@ -222,7 +222,7 @@
        /* Create enough structures to hold all arguments */        for (p = format; *p != '\0'; p++)
-               if (*p == '%')                  /* counts %% as two, so
overcounts */
+               if ((*p == '%') || (*p == '*'))         /* counts %% as
two, so overcounts */                        percents++;
        /* Need to use malloc() because memory system might not be
started yet. */

Regards,

Rémi Zara

Le 11 avr. 05, à 22:31, Tom Lane a écrit :

> Rémi Zara <remi_zara@mac.com> writes:
>> The crash occurs in pg_sprintf,  work on which has been done beginning
>> march 11th....
>
> Offhand I'd bet it's overrunning its malloc'd arrays because the loop
> at
> the top doesn't count "*" as needing a fmtpos position.
>
>             regards, tom lane
>
>
--
Rémi Zara
http://www.remi-zara.net/

Le 12 avr. 05, à 08:23, Rémi Zara a écrit :

> Hi,
>
> With the following patch, the crash still occurs in the same way. But
> it does seem, reading the code, that it still may be necessary.

Well, I've re-run the checks several times after a clean make and it
does not crash anymore. So the patch seems to help !

Please consider applying it.

Regards,

Rém Zara

> RCS file: /projects/cvsroot/pgsql/src/port/snprintf.c,v
> retrieving revision 1.26
> diff -u -r1.26 snprintf.c
> --- snprintf.c  20 Mar 2005 13:54:53 -0000      1.26
> +++ snprintf.c  12 Apr 2005 06:08:02 -0000
> @@ -222,7 +222,7 @@
>
>         /* Create enough structures to hold all arguments */
>         for (p = format; *p != '\0'; p++)
> -               if (*p == '%')                  /* counts %% as two,
> so overcounts */
> +               if ((*p == '%') || (*p == '*'))         /* counts %%
> as two, so overcounts */
>                         percents++;
>
>         /* Need to use malloc() because memory system might not be
> started yet. */
>
> Regards,
>
> Rémi Zara
>
> Le 11 avr. 05, à 22:31, Tom Lane a écrit :
>
>> =?ISO-8859-1?Q?R=E9mi_Zara?= <remi_zara@mac.com> writes:
>>> The crash occurs in pg_sprintf,  work on which has been done
>>> beginning
>>> march 11th....
>>
>> Offhand I'd bet it's overrunning its malloc'd arrays because the loop
>> at
>> the top doesn't count "*" as needing a fmtpos position.
>>
>>             regards, tom lane
>>
>>
> --
> Rémi Zara
> http://www.remi-zara.net/
>
--
Rémi Zara
http://www.remi-zara.net/

=?ISO-8859-1?Q?R=E9mi_Zara?= <remi_zara@mac.com> writes:
> Well, I've re-run the checks several times after a clean make and it
> does not crash anymore. So the patch seems to help !

Thought it might ;-)

> Please consider applying it.

Done.

            regards, tom lane