Re: Tom Lane 2014-05-14 <1357.1400028...@sss.pgh.pa.us> > Christoph Berg <c...@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 -- c...@df7cb.de | http://www.df7cb.de/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers