Re: plpython tests fail against python 3.14 under Valgrind - Mailing list pgsql-hackers

From Tom Lane
Subject Re: plpython tests fail against python 3.14 under Valgrind
Date
Msg-id 2322557.1786409782@sss.pgh.pa.us
Whole thread
In response to plpython tests fail against python 3.14 under Valgrind  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: Discard ORDER BY/DISTINCT when an ANY/IN sublink is pulled up to a join
List pgsql-hackers
Alexander Lakhin <exclusion@gmail.com> writes:
> As buildfarm animal skink shows, upgrade to Python 3.14 breaks plpython
> tests under Valgrind [1]:
>   61/400 plpython - postgresql:plpython/regress ERROR             49.88s   exit status 1

Yeah, I can reproduce this here, using Fedora 43 (with
python3-3.14.6-1.fc43.x86_64 and valgrind-3.27.1-1.fc43.x86_64).
As you say, it doesn't reproduce on master; I didn't take the trouble
to bisect.

> It's also not reproduced on master, probably just because of a bit lesser
> stack usage. I've bisected the anomaly and found what makes master pass
> the tests: aeb07c55f.

Actually, I think it's the other way around: master uses more stack.
In v19, tzload() does this:

    union local_storage *lsp = malloc(sizeof *lsp);
    ...
    free(lsp);

while in master it does this:

    union local_storage *lsp;
    union local_storage ls;

    lsp = &ls;

That's a sizeable amount of stack getting chewed:

(gdb) p sizeof(union local_storage)
$1 = 72240

However, we surely don't invoke tzload() while running any Python
code.  What I think must be happening is that at postmaster start,
or possibly backend start, we invoke tzload() while setting the
timezone GUC, and this causes a bunch of stack pages to get allocated,
more than we have in the v19 code path.  Somehow, python and valgrind
interact badly when there's not much pre-existing stack allocation.
It's pretty unclear which one is to blame, but it seems like it can't
be our fault.  (Although ... surely the standard python executable
invokes libpython with little pre-existing stack?  If that doesn't
trigger this problem, what are we doing differently?)

Anyway, I've confirmed that the attached patch makes the problem
go away here.  Unless somebody wants to expend brain cells on
running the underlying issue to ground, I think we should just
apply this to the back branches and be happy.  A variant plan
could be to do it like this #ifdef USE_VALGRIND and otherwise
keep the old code, but that seems unduly paranoid to me.

            regards, tom lane

diff --git a/src/timezone/localtime.c b/src/timezone/localtime.c
index fb04b4cf6bf..1a8088b520c 100644
--- a/src/timezone/localtime.c
+++ b/src/timezone/localtime.c
@@ -588,17 +588,10 @@ tzloadbody(char const *name, char *canonname, struct state *sp, bool doextend,
 int
 tzload(char const *name, char *canonname, struct state *sp, bool doextend)
 {
-    union local_storage *lsp = malloc(sizeof *lsp);
+    union local_storage ls;
+    union local_storage *lsp = &ls;

-    if (!lsp)
-        return errno;
-    else
-    {
-        int            err = tzloadbody(name, canonname, sp, doextend, lsp);
-
-        free(lsp);
-        return err;
-    }
+    return tzloadbody(name, canonname, sp, doextend, lsp);
 }

 static bool

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: CREATE SUBSCRIPTION ... SERVER vs. pg_dump, etc.
Next
From: Haibo Yan
Date:
Subject: Re: Introduce psystem() to replace system()