Re: Tom Lane 2014-05-14 <1357.1400028161@sss.pgh.pa.us>
> Christoph Berg <cb@df7cb.de> writes:
> > Building 9.4 beta1 on Debian sid/i386 fails during the regression
> > tests. amd64 works fine, as does i386 on the released distributions.
>
> It would appear that something is wrong with check_stack_depth(),
> and/or getrlimit(RLIMIT_STACK) is lying to us about the available stack.
> None of that logic has changed in awhile. You might try checking what
> the max_stack_depth GUC gets set to by default in each build, and how that
> compares to what "ulimit -s" has to say. If it looks sane, try tracing
> through check_stack_depth.
ulimit -s is 8192 (kB); max_stack_depth is 2MB.
check_stack_depth looks right, max_stack_depth_bytes there is 2097152
and I can see stack_base_ptr - &stack_top_loc grow over repeated
invocations of the function (stack_depth itself is optimized out).
Still, it never enters "if (stack_depth > max_stack_depth_bytes...)".
Using "b check_stack_depth if (stack_base_ptr - &stack_top_loc) >
1000000", I could see the stack size at 1000264, though when I then
tried with > 1900000, it caught SIGBUS again.
In the meantime, the problem has manifested itself also on other
architectures: armel, armhf, and mipsel (the build logs are at [1],
though they don't contain anything except a "FATAL: the database
system is in recovery mode").
[1] https://buildd.debian.org/status/logs.php?pkg=postgresql-9.4&ver=9.4~beta1-1
Interestingly, the Debian buildd managed to run the testsuite for
i386, while I could reproduce the problem on the pgapt build machine
and on my notebook, so there must be some system difference. Possibly
the reason is these two machines are running a 64bit kernel and I'm
building in a 32bit chroot, though that hasn't been a problem before.
Christoph
--
cb@df7cb.de | http://www.df7cb.de/