Re: Yet another fast GiST build

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
Cc: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Yet another fast GiST build
Date: 2020-10-06 13:19:31
Message-ID: 867aacfd-d1af-3eed-5e40-dfc334668d65@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/10/2020 14:05, Pavel Borisov wrote:
> I've been making tests with memory sanitizer

Thanks!

> and got one another error
> in regression test create_index:
> CREATE INDEX gpointind ON point_tbl USING gist (f1);
> server closed the connection unexpectedly
>
> with logfile:
> gistproc.c:1714:28: runtime error: 1e+300 is outside the range of
> representable values of type 'float'
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior gistproc.c:1714:28
>
> gistproc.c:
> 1714     z = point_zorder_internal(p->x, p->y);
>
> Consider this a minor issue but unrelated to the other issues discussed.
> It is reproduced on the last master
> commit 0a3c864c32751fd29d021929cf70af421fd27370 after all changes into
> Gist committed.
>
> cflags="-DUSE_VALGRIND -Og -O0 -fsanitize=address -fsanitize=undefined
> -fno-sanitize-recover=all -fno-sanitize=alignment -fstack-protector"

You get the same error with:

select (float8 '1e+300')::float4;

float.c:1204:11: runtime error: 1e+300 is outside the range of
representable values of type 'float'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior float.c:1204:11 in

It boils down to casting a C double to float, when the value doesn't fit
in float. I'm surprised that's undefined behavior, but I'm no C99
lawyer. The code in dtof() expects it to yield Inf.

I'm inclined to shrug this off and say that the sanitizer is being
over-zealous. Is there some compiler flag we should be setting, to tell
it that we require specific behavior? Any other ideas?

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-10-06 13:22:29 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Previous Message Bharath Rupireddy 2020-10-06 13:06:34 Re: Logical Replication - detail message with names of missing columns