Re: pgsql: Refactor dlopen() support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgsql: Refactor dlopen() support
Date
Msg-id 14508.1536301857@sss.pgh.pa.us
Whole thread Raw
Responses Re: pgsql: Refactor dlopen() support  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Collation versioning
Next
From: David Rowley
Date:
Subject: Small performance tweak to run-time partition pruning