Re: --with-llvm on 32-bit platforms? - Mailing list pgsql-hackers

From Dmitry Mityugov
Subject Re: --with-llvm on 32-bit platforms?
Date
Msg-id b527cb2bd4ae3c6cfd5ea7caf79cb3b5@postgrespro.ru
Whole thread Raw
In response to Re: --with-llvm on 32-bit platforms?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane писал(а) 2025-09-16 03:31:
> Dmitry Mityugov <d.mityugov@postgrespro.ru> writes:
>> Tom Lane писал(а) 2025-09-15 23:21:
>>> Interesting, but again, how about a stack trace?
>
>
>> performing post-bootstrap initialization ... TRAP: failed Assert("(X &
>> 0xFFFFFFFF00000000) == 0"), File:
>> "../../../../src/include/postgres.h",
>> Line: 324, PID: 427452
>
>>
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(ExceptionalCondition+0x6b)
>> [0x56c990cb]
>>
/home/dd/projects/postgres/vanilla/planb/postgres/master/tmp_install/usr/local/pgsql/bin/postgres(toast_tuple_init+0x2f1)
>> [0x567c19e1]
>
> Ah-hah.  What's going on there is that toast_tuple_init does
>
>             old_value =
>                 (struct varlena *)
> DatumGetPointer(ttc->ttc_oldvalues[i]);
>             new_value =
>                 (struct varlena *) DatumGetPointer(ttc->ttc_values[i]);
>
> before checking if the values are NULL.  Now, this is at least
> theoretically okay because it doesn't try to dereference either
> pointer until it's checked the isnull flags.  But the Datum it's
> reading might well be garbage, thus triggering your assertion.
>
> I don't see a really nice way to avoid this.  We could perhaps
> do something like
>
>             old_value =
>                 (struct varlena *)
>                     (ttc->ttc_oldisnull[i] ? NULL :
> DatumGetPointer(ttc->ttc_oldvalues[i]));
>
> but adding extra cycles here isn't very appetizing.

Thank you for the explanation.

> If you want to pursue it further you could temporarily patch
> toast_tuple_init and then see if you get any further, but I'm
> not sure you'll learn anything interesting.  I think Munro
> has put his finger on the problem.

This, unrelated to --with-llvm, task, can be pursued on a 64-bit Linux,
provided the system has the multilibs installed and -m32 was added to
the list of compiler options, like in

make distclean -s && ./configure CFLAGS="-Og -m32" --enable-cassert &&
make -sj23 && make check

I created a secondary DatumGetPointer() function, with a bit different
name and without the assert, reproduced the failure using the command
line above, replaced all calls to DatumGetPointer() function in
toast_tuple_init() with the version without assert... And have found no
more problems so far. At least `make check` passes clearly.

Thank you again



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: AioCtl Shared Memory size fix
Next
From: Nitin Motiani
Date:
Subject: pgstattuple "unexpected zero page" for gist and hash indexes