From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Refactor dlopen() support
In-reply-to: <E1fxqjl-0003YS-NS@gemulon.postgresql.org>
References: <E1fxqjl-0003YS-NS@gemulon.postgresql.org>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Thu, 06 Sep 2018 09:38:05 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14507.1536301857.1@sss.pgh.pa.us>
Date: Fri, 07 Sep 2018 02:30:57 -0400
Message-ID: <14508.1536301857@sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter_e@gmx.net> writes:
> Refactor dlopen() support

Buildfarm member locust doesn't like this much.  I've been able to
reproduce the problem on an old Mac laptop running the same macOS release,
viz 10.5.8.  (Note that we're not seeing it on earlier or later releases,
which is odd in itself.)  According to my machine, the crash is happening
here:

#0  _PG_init () at plpy_main.c:98
98              *plpython_version_bitmask_ptr |= (1 << PY_MAJOR_VERSION);

and the reason is that the rendezvous variable sometimes contains garbage.
Most sessions correctly see it as initially zero, but sometimes it
contains

(gdb) p plpython_version_bitmask_ptr
$1 = (int *) 0x1d

and I've also seen

(gdb) p plpython_version_bitmask_ptr
$1 = (int *) 0x7f7f7f7f

It's mostly repeatable but not completely so: the 0x1d case seems
to come up every time through the plpython_do test, but I don't
always see the 0x7f7f7f7f case.  (Maybe that's a timing artifact?
It takes a variable amount of time to recover from the first crash
in plpython_do, so the rest of the plpython test run isn't exactly
operating in uniform conditions.)

No idea what's going on here, and I'm about out of steam for tonight.

			regards, tom lane