Hi Andrew, many thanks for Your efforts! Lets see what I get out of this. First, it seems I can reproduce the fault on my build machine (IvyBridge core-i5) in the i386-chroot as well - which is not a surprize according to Your explanations. On Fri, Mar 08, 2019 at 04:51:47PM +0000, Andrew Gierth wrote: ! MOVAPS is an SSE (not SSE2) instruction; it's enabled by virtue of the ! fact that you used -march=pentium3 (the pentium3 supports SSE but not ! SSE2). The "A" stands for "aligned"; an unaligned source address causes ! an exception. %esp+0x20 is not correctly aligned for the instruction. Okay so far. I was occasionally wondering if that pentium3 option would effect anything at all. Now we see, it does. ;) ! GCC defaults to using a 16-byte stack alignment, but it relies on the ! caller to align the stack too, so if a GCC-compiled function is called ! from code that doesn't align the stack, then this kind of error can ! result. I do not know offhand (but I plan to find out) what clang's ! default stack alignment on i386 is. Well, what caused me a headache this evening is: who would be the caller in this case, as -from my understanding- it is just postgreSQL running? Now from Your newer mail this riddle does clear up well. In my build environment, I can now create and start a new db-cluster and issue only the single command "CREATE ROLE bacula;" and it will crash - but then again I have to wait for the next checkpointer. ! You can tell GCC to realign the stack itself using the -mstackrealign ! option. Yepp, that appears to solve it. So, as there is a fix now, I'm pondering about who would be the responsible to apply it? * the system owner (alongside with the CPU definition) * the port maintainer (alongside with the compiler choice) * the postgres configure script ! This problem shows up only with GCC and not with clang because clang ! does not attempt to use SSE to vectorize this particular piece of code. ! The non-vectorized implementation generated by clang has no special ! requirements for stack alignment. But at the end of the day this is not ! a problem with PostgreSQL - it would show up with any code compiled with ! GCC where the compiler had elected to use SSE instructions for ! optimization. Well, its clearly my fault, coming up with that pentium3 option. *gg* rgds, P.
