Thread: make check-world regress failed
Hi, PostgreSQL check-world regress failed with current GIT HEAD on my Kubuntu 14.10. uname -a Linux vlD-kuci 3.16.0-24-generic #32-Ubuntu SMP Tue Oct 28 13:13:18 UTC 2014 i686 athlon i686 GNU/Linux gdb -d /home/src/postgresql-devel/postgresql-git/postgresql/src -c core ... Loaded symbols for /home/src/postgresql-devel/dev-build/src/test/regress/regress.so (gdb) bt #0 0xb76ecc7c in __kernel_vsyscall () #1 0xb7075577 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb7076cf3 in __GI_abort () at abort.c:89 #3 0x084c326a in ?? () #4 0x0a56c3b8 in ?? () #5 0xb76d232f in pg_atomic_init_u64 (ptr=0xbfa16fd4, val=0) at /home/src/postgresql-devel/postgresql-git/postgresql/src/include/port/atomics.h:445 #6 0xb76d50e4 in test_atomic_uint64 () at /home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/regress.c:1022 #7 0xb76d5756 in test_atomic_ops (fcinfo=0xa57c76c) at /home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/regress.c:1114 #8 0x0825bfee in ?? () ... My patch solved check-world regress fail. Best regards Vladimir Kokovic DP senior
Attachment
On 11/23/2014 08:37 PM, Vladimir Koković wrote: > PostgreSQL check-world regress failed with current GIT HEAD on my Kubuntu > 14.10. > > uname -a > Linux vlD-kuci 3.16.0-24-generic #32-Ubuntu SMP Tue Oct 28 13:13:18 UTC > 2014 i686 athlon i686 GNU/Linux > > gdb -d /home/src/postgresql-devel/postgresql-git/postgresql/src -c core > ... > Loaded symbols for > /home/src/postgresql-devel/dev-build/src/test/regress/regress.so > (gdb) bt > #0 0xb76ecc7c in __kernel_vsyscall () > #1 0xb7075577 in __GI_raise (sig=sig@entry=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > #2 0xb7076cf3 in __GI_abort () at abort.c:89 > #3 0x084c326a in ?? () > #4 0x0a56c3b8 in ?? () > #5 0xb76d232f in pg_atomic_init_u64 (ptr=0xbfa16fd4, val=0) at > /home/src/postgresql-devel/postgresql-git/postgresql/src/include/port/atomics.h:445 > #6 0xb76d50e4 in test_atomic_uint64 () at > /home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/regress.c:1022 > #7 0xb76d5756 in test_atomic_ops (fcinfo=0xa57c76c) at > /home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/regress.c:1114 > #8 0x0825bfee in ?? () > ... Andres, have you had a chance to look at this? On 32-bit x86, arch-x86.h leaves PG_HAVE_ATOMIC_U64_SUPPORT undefined. But generic-gcc.h, which is included later, then defines it. pg_atomic_init_u64 does AssertPointerAlignment(ptr, 8) on the variable, but there is no guarantee that it is 8-bytes aligned on x86. > My patch solved check-world regress fail. - Heikki
On 2014-12-04 16:38:45 +0200, Heikki Linnakangas wrote: > On 11/23/2014 08:37 PM, Vladimir Koković wrote: > >PostgreSQL check-world regress failed with current GIT HEAD on my Kubuntu > >14.10. > > > >uname -a > >Linux vlD-kuci 3.16.0-24-generic #32-Ubuntu SMP Tue Oct 28 13:13:18 UTC > >2014 i686 athlon i686 GNU/Linux > > > >gdb -d /home/src/postgresql-devel/postgresql-git/postgresql/src -c core > >... > >Loaded symbols for > >/home/src/postgresql-devel/dev-build/src/test/regress/regress.so > >(gdb) bt > >#0 0xb76ecc7c in __kernel_vsyscall () > >#1 0xb7075577 in __GI_raise (sig=sig@entry=6) at > >../nptl/sysdeps/unix/sysv/linux/raise.c:56 > >#2 0xb7076cf3 in __GI_abort () at abort.c:89 > >#3 0x084c326a in ?? () > >#4 0x0a56c3b8 in ?? () > >#5 0xb76d232f in pg_atomic_init_u64 (ptr=0xbfa16fd4, val=0) at > >/home/src/postgresql-devel/postgresql-git/postgresql/src/include/port/atomics.h:445 > >#6 0xb76d50e4 in test_atomic_uint64 () at > >/home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/regress.c:1022 > >#7 0xb76d5756 in test_atomic_ops (fcinfo=0xa57c76c) at > >/home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/regress.c:1114 > >#8 0x0825bfee in ?? () > >... > > Andres, have you had a chance to look at this? Nope, missed it somehow. > On 32-bit x86, arch-x86.h leaves PG_HAVE_ATOMIC_U64_SUPPORT undefined. But > generic-gcc.h, which is included later, then defines it. That's fine. The only reason arch-x86.h implements anything itself is that that allows older compilers than relying on intrinsics. But implementing 64bit atomics is too annoying by hand and isn't currently required. > pg_atomic_init_u64 does AssertPointerAlignment(ptr, 8) on the variable, but > there is no guarantee that it is 8-bytes aligned on x86. Hrmpf. Annoying. Gcc for a while claimed that was guaranteed, but, if I understood the tickets correctly, gave up on that. Unfortunately we have to rely (IIRC) on that for (quite old) x86s and some other architectures. It doesn't seem to be a problem on any native 64bit platform, because 64bit variables are 8byte aligned natively there. I think it can relatively easily be fixed by something like the attached. Don't have a pure 32bit environment to test though - the problem isn't reproducable in a 32bit chroot... Vladimir, if you apply that patch, do things work for you? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Attachment
Hi, Thanks Andres, i686 check-world passed with your atomic-uint64-alignment.patch. Vladimir Kokovic Belgrade Serbia, 9.Jan 2015 ------- Forwarded message ------- From: "Andres Freund" <andres@2ndquadrant.com> To: "Heikki Linnakangas" <hlinnakangas@vmware.com> Cc: "Vladimir Koković" <vladimir.kokovic@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org> Subject: Re: [HACKERS] make check-world regress failed Date: Thu, 08 Jan 2015 21:46:35 +0100 On 2014-12-04 16:38:45 +0200, Heikki Linnakangas wrote: > On 11/23/2014 08:37 PM, Vladimir Koković wrote: > >PostgreSQL check-world regress failed with current GIT HEAD on my > Kubuntu > >14.10. > > > >uname -a > >Linux vlD-kuci 3.16.0-24-generic #32-Ubuntu SMP Tue Oct 28 13:13:18 UTC > >2014 i686 athlon i686 GNU/Linux > > > >gdb -d /home/src/postgresql-devel/postgresql-git/postgresql/src -c core > >... > >Loaded symbols for > >/home/src/postgresql-devel/dev-build/src/test/regress/regress.so > >(gdb) bt > >#0 0xb76ecc7c in __kernel_vsyscall () > >#1 0xb7075577 in __GI_raise (sig=sig@entry=6) at > >../nptl/sysdeps/unix/sysv/linux/raise.c:56 > >#2 0xb7076cf3 in __GI_abort () at abort.c:89 > >#3 0x084c326a in ?? () > >#4 0x0a56c3b8 in ?? () > >#5 0xb76d232f in pg_atomic_init_u64 (ptr=0xbfa16fd4, val=0) at > >/home/src/postgresql-devel/postgresql-git/postgresql/src/include/port/atomics.h:445 > >#6 0xb76d50e4 in test_atomic_uint64 () at > >/home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/regress.c:1022 > >#7 0xb76d5756 in test_atomic_ops (fcinfo=0xa57c76c) at > >/home/src/postgresql-devel/postgresql-git/postgresql/src/test/regress/regress.c:1114 > >#8 0x0825bfee in ?? () > >... > > Andres, have you had a chance to look at this? Nope, missed it somehow. > On 32-bit x86, arch-x86.h leaves PG_HAVE_ATOMIC_U64_SUPPORT undefined. > But > generic-gcc.h, which is included later, then defines it. That's fine. The only reason arch-x86.h implements anything itself is that that allows older compilers than relying on intrinsics. But implementing 64bit atomics is too annoying by hand and isn't currently required. > pg_atomic_init_u64 does AssertPointerAlignment(ptr, 8) on the variable, > but > there is no guarantee that it is 8-bytes aligned on x86. Hrmpf. Annoying. Gcc for a while claimed that was guaranteed, but, if I understood the tickets correctly, gave up on that. Unfortunately we have to rely (IIRC) on that for (quite old) x86s and some other architectures. It doesn't seem to be a problem on any native 64bit platform, because 64bit variables are 8byte aligned natively there. I think it can relatively easily be fixed by something like the attached. Don't have a pure 32bit environment to test though - the problem isn't reproducable in a 32bit chroot... Vladimir, if you apply that patch, do things work for you? Greetings, Andres Freund -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Hi, On 2015-01-09 04:59:56 +0100, Vladimir Koković wrote: > Thanks Andres, i686 check-world passed with your > atomic-uint64-alignment.patch. Thanks for the report and testing! I've pushed the fix. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services