Andres Freund <andres@anarazel.de> writes:
> On 2022-11-29 20:44:34 -0500, Tom Lane wrote:
>> Backtrace stopped: frame did not save the PC
> Do you have any idea why the stack can't be unwound further here? Is it
> possibly indicative of a corrupted stack? I guess we'd need to dig into
> the netbsd libc code :(
I did do some digging in that area previously when we were seeing this
on HPPA, and determined that the assembly code in that area was not
bothering to establish a standard stack frame, for no very obvious
reason :-(. I haven't studied their equivalent PPC code, but apparently
it's equally cavalier. I recall trying to hack the HPPA code to make
it set up the stack frame correctly, without success, but I didn't
try very hard. Maybe I'll have a go at that on the PPC side.
> What libraries is postgres linked against? I don't know whether -z now only
> affects the "top-level" dependencies of postgres, or also the dependencies of
> shared libraries that haven't been built with -z now. The only dependencies
> that I could see being relevant are libintl and openssl.
Hmm. mamba is using both --enable-nls and --with-openssl, but
I can't see a reason why the postmaster would be interacting with
OpenSSL post-startup in test cases that don't use SSL. Perhaps
libintl is doing something it shouldn't?
> You could try if anything changes if you set LD_BIND_NOW, that should trigger
> "recursive" dependencies to be loaded eagerly as well.
Googling LD_BIND_NOW suggests that that's a Linux thing; do you know that
it should have an effect on NetBSD?
regards, tom lane
