While trying to compile dev-db/postgresql-base-8.4.4-r1 (upgrading from dev-db/postgresql-base-8.4.4) I got the following error: configure: error: thread test program failed This platform is not thread-safe. Check the file 'config.log' for the exact reason. You can use the configure option --enable-thread-safety-force to force threads to be enabled. But you must then run the program in src/test/thread and add locking function calls to your applications to guarantee thread safety. Reproducible: Always Steps to Reproduce: 1. emerge dev-db/postgresql-base-8.4.4-r1 on amd64 2. configure fails Actual Results: Configure fails to detect threads Expected Results: Configure should properly detect threads
Created attachment 233967 [details] config.log
Created attachment 233969 [details] emerge --info
The problem is not in the configure process, it's in the environment. I've been banging my head against this one. It seems those who run an ~amd64 system don't have this issue, but those with an amd64 do run into it. This leads me to believe there is one specific package -- or group of packages -- that need to be present for threads to be properly enabled. I don't have an AMD64 system, production or testing, to track down the problem and I'd greatly appreciate any effort you could put forth on this issue.
P.S.: --thread-safety-force is not the answer here. That only disables the test, it does not actually force thread safety.
Okay, I am willing to help you track down the issue if you can give me an idea of where to start.
Btw: I was able to compile this package without any issue on a server that is amd64 also. Apparently there is some difference between the server and my desktop (where I ran into this problem). Here is the server's emerge --info: Portage 2.1.8.3 (default/linux/amd64/10.0/server, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r10 x86_64) ================================================================= System uname: Linux-2.6.31-gentoo-r10-x86_64-AMD_Opteron-tm-_Processor_250-with-gentoo-1.12.13 Timestamp of tree: Fri, 04 Jun 2010 06:30:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 4.0_p37 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.3.4, 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/eselect/postgresql /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://distfiles.gentoo.org http://gentoo.ccccom.com" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow acl amd64 berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm iconv ipv6 mmx modules mudflap multilib mysql ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session snmp spl sse sse2 ssl sysfs tcpd truetype unicode xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa via vmware voodoo" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I'm getting the same error, but I'm on an x86 platform. Will attach my build and config logs and emerge info as well.
Created attachment 234131 [details] build.log for x86 system
Created attachment 234133 [details] config.log for x86 system
Created attachment 234135 [details] emerge --info for x86 system
(In reply to comment #6) Well, the first interesting thing I note is that the 'threads' USE flag isn't enabled globally for your server. Second, you're missing a few of the autoconf and automake versions on the server that are present on the desktop. Finally, the big ticket item would be the >2.6.31 kernel, this also goes for Wyatt, on the desktop and 2.6.31 on the server. So, of those things there may be a starting point. The quickest thing may be to downgrade to 2.6.31 and have the /usr/src/linux symlink point to the 2.6.31 source as well. If that doesn't do anything, see if the other versions of automake and autoconf are interfering. If that doesn't do anything, disable 'threads' globally, taking care to note which packages are going to be recompiled. If that still doesn't work, I'll think of something else to go after.
I have been getting this problem regularly on ONE of my three nearly identical amd64 machines for a long time now. The answer in the past has been to remove sandbox from make.conf. Today I got the error again (with no sandbox). So I installed the testing version of sandbox (2.2) and the build worked! So try getting sandbox-2.2.
(In reply to comment #12) > I have been getting this problem regularly on ONE of my three nearly identical > amd64 machines for a long time now. The answer in the past has been to remove > sandbox from make.conf. Today I got the error again (with no sandbox). So I > installed the testing version of sandbox (2.2) and the build worked! So try > getting sandbox-2.2. > From what I've found, sandbox-2.2 isn't a consistent solution or it isn't THE solution. But, it could be a part of the solution.
By the way, this is related to bug #300964. There's a test in the first couple of comments that will check if dev-db/postgresql-base was really built thread safe or not. The reporter there never ran into the thread check failure during configure time like those of you have here. Still, it built being non-thread safe.f This is why --enable-thread-safety-force is not the answer.
What I've found in my syslog is a segfault in libsandbox.so, when running sandbox 1.6-r2: Jun 7 08:55:01 server kernel: conftest[22314]: segfault at 0 ip 7fa1a54895b8 sp 7fa1a226df20 error 6 in libsandbox.so[7fa1a5486000+b000] This happens during the conftest of the postgresql package.
(In reply to comment #15) > What I've found in my syslog is a segfault in libsandbox.so, when running > sandbox 1.6-r2: > Jun 7 08:55:01 server kernel: conftest[22314]: segfault at 0 ip 7fa1a54895b8 > sp 7fa1a226df20 error 6 in libsandbox.so[7fa1a5486000+b000] > > This happens during the conftest of the postgresql package. > I've done a Google search trying to find out what error 6 means, but instead found a lot of Gentoo pages that all recommend running this command: # FEATURES="-sandbox" emerge -1av sandbox Give that a shot and see what it does. I'll continue to look for the definition of error 6.
(In reply to comment #16) > I've done a Google search trying to find out what error 6 means, but instead > found a lot of Gentoo pages that all recommend running this command: > > # FEATURES="-sandbox" emerge -1av sandbox > > Give that a shot and see what it does. After running the above command and re-trying to emerge postgresql-8.4.4-r1, the error message in syslog now refers to an error 4 in libc, and the build still fails with the same error message. Jun 7 14:05:22 server kernel: conftest[4070]: segfault at 7f7b87a91008 ip 7f7b85c95ac0 sp 7f7b84497fd8 error 4 in libc-2.10.1.so[7f7b85c1a000+14f000]
(In reply to comment #17) > (In reply to comment #16) > > I've done a Google search trying to find out what error 6 means, but instead > > found a lot of Gentoo pages that all recommend running this command: > > > > # FEATURES="-sandbox" emerge -1av sandbox > > > > Give that a shot and see what it does. > > After running the above command and re-trying to emerge postgresql-8.4.4-r1, > the error message in syslog now refers to an error 4 in libc, and the build > still fails with the same error message. > > Jun 7 14:05:22 server kernel: conftest[4070]: segfault at 7f7b87a91008 ip > 7f7b85c95ac0 sp 7f7b84497fd8 error 4 in libc-2.10.1.so[7f7b85c1a000+14f000] > I guess we now try reemerging glibc.
Interesting. Is it possible this is a problem compiling as root? I tried the emerge this morning and it failed as I expected. I then added "userpriv" to my FEATURES in make.conf. I did not add "usersandbox". I tried the emerge again and it worked without errors.
(In reply to comment #19) > Interesting. Is it possible this is a problem compiling as root? > > I tried the emerge this morning and it failed as I expected. I then added > "userpriv" to my FEATURES in make.conf. I did not add "usersandbox". > > I tried the emerge again and it worked without errors. > Have you run the test program from bug #300964?
(In reply to comment #20) > (In reply to comment #19) > > Interesting. Is it possible this is a problem compiling as root? > > > > I tried the emerge this morning and it failed as I expected. I then added > > "userpriv" to my FEATURES in make.conf. I did not add "usersandbox". > > > > I tried the emerge again and it worked without errors. > > > Have you run the test program from bug #300964? > I had the exact same configure problem and today I tried emerging postgresql-base with FEATURES="userpriv" (as root). It perfectly worked and the pgtest-Program tells me, that my libpg is threadsafe. My emerge --info: Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.4.4, glibc-2.10.1-r1, 2.6.32-gentoo-r7 x86_64) ================================================================= System uname: Linux-2.6.32-gentoo-r7-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9450_@_2.66GHz-with-gentoo-1.12.13 Timestamp of tree: Sun, 13 Jun 2010 02:25:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA dlj-1.1 googleearth" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-O2 -march=native -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -pipe" DISTDIR="/mnt/distfiles/" FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="de_DE.UTF8" LC_ALL="de_DE.utf8" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j5" PKGDIR="/mnt/portage/packages/" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/mnt/portage/" PORTDIR_OVERLAY="/usr/local/overlays/xmms /usr/local/overlays/vbox /usr/local/overlays/fixes" SYNC="rsync://192.168.0.254/gentoo-portage" USE="64bit 7zip X a52 aac acpi aim alsa amd64 amr asf audiofile avi bash-completion bmp bzip2 cairo cdb cdda cddb cdparanoia cdr crypt css cuda cups curl custom-optimization cxx dbus dirac dts dvb dvd dvdr dvdread emerald encode exif faac faad fame fbcondecor ffmpeg flac foomaticdb freetype fuse gif glibc-omitfp glitz glut glx gpm gtk gtk2 iconv icq imlib insecure-savers ipv6 java java6 javascript joystick jpeg lcdfilter lzo mad midi mikmod mjpeg mmx mmxext mng modplug modules mozsvg mp3 mp4 mpeg mplayer mudflap multilib ncurses new-login nls no_wxgtk1 nocd nptl nptlonly ntfs nvidia offensive ogg oggvorbis openal opengl openmp pam pango pdf perl pg-intdatetime png ppds projectm qt3support quicktime readline rtc s3tc samba scanner schroedinger sdl session slang smp spell sse sse2 sse3 ssl ssse3 svg sysfs tcpd teletext tga theora threads tiff truetype unicode usb userlocales vcd vdpau vorbis vpx wxwindows x264 xcomposite xine xinerama xml xorg xscreensaver xulrunner xv xvid xvmc yahoo yv12 zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" FOO2ZJS_DEVICES="hp1000 hp1005 hp1018 hp1020 hp1215 hp1500 hp1600 hp2600n hpp1005 hpp1006 hpp1007 hpp1008 hpp1505" INPUT_DEVICES="keyboard mouse joystick evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" RUBY_TARGETS="ruby18" SANE_BACKENDS="hp hp3500 hp3900 hp4200 hp5400 hp5590 hpljm1005 hpsj5s" USERLAND="GNU" VIDEO_CARDS="nvidia nv vesa fbdev" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I thought I posted to this, oh well, I'm posting it now. The solution so far has been, for -base: # FEATURES="userpriv" emerge dev-db/postgresql-base And as you'll most likely hit a related problem with -server: # FEATURES="-sandbox" emerge dev-db/postgresql-server
(In reply to comment #22) > I thought I posted to this, oh well, I'm posting it now. > > The solution so far has been, for -base: > > # FEATURES="userpriv" emerge dev-db/postgresql-base > > And as you'll most likely hit a related problem with -server: > > # FEATURES="-sandbox" emerge dev-db/postgresql-server > Well... I compiled postgresql-server with FEATURES="userpriv", too... Compiled just fine and pgtest says that it's thread-safe.
After re-emerging glibc-2.10.1-r1 with FEATURES="userpriv", the subsequent compile of postgresql-base-8.4.4-r1 went through fine, as well as postgresql-server-8.4.4-r1.
(In reply to comment #24) > After re-emerging glibc-2.10.1-r1 with FEATURES="userpriv", the subsequent > compile of postgresql-base-8.4.4-r1 went through fine, as well as > postgresql-server-8.4.4-r1. > To clarify a bit, you did: FEATURES="userpriv" emerge glibc And then did: emerge dev-db/postgresql-server Is that correct?
(In reply to comment #25) > (In reply to comment #24) > > After re-emerging glibc-2.10.1-r1 with FEATURES="userpriv", the subsequent > > compile of postgresql-base-8.4.4-r1 went through fine, as well as > > postgresql-server-8.4.4-r1. > > > > To clarify a bit, you did: > > FEATURES="userpriv" emerge glibc > > And then did: > emerge dev-db/postgresql-server > > Is that correct? > I added "userpriv" to the FEATURES in my make.conf, then emerged glibc. After that, I did an emerge --resume, since postgresql-base-8.4.4-r1 as well as postgresql-server-8.4.4-r1 were still in the merge queue. Both packages got compiled without any error messages, and postgres is running fine.
I just compiled postgresql-base and postgresql-server with userpriv (FEATURES="userpriv" emerge -uDN postgresql-base postgresql-server). Worked fine. BTW: Still the same error with postgresql-base-8.4.4-r2!
FYI, I still have this problem with the new -r2 version of the ebuild.
The -r2 ebuild was to fix a patch bug. Don't fret! This bug is at the forefront of my mind.
I have several amd64 systems upon which postgresql-server/base 8.4 emerge just fine. However, when I tried to emerge version 9-beta2, I run into the "configure: error: thread test program failed" issue. I will attach my emerge --info, as well as the config.log of the failed 9.0-beta2
Created attachment 235839 [details] config.log for failed 9.0-beta2 emerge
Created attachment 235841 [details] emerge --info from system where 9.0-beta2 failed to emerge
A few of us got together and really dug into this. We found out that the thread test does perform cleanly, and would exit cleanly if it didn't get this from Sandbox: Program received signal SIGSEGV, Segmentation fault. free (ptr=0x7f15d8552008) at ../../sandbox-1.6/libsandbox/memory.c:37 ../../sandbox-1.6/libsandbox/memory.c: No such file or directory. in ../../sandbox-1.6/libsandbox/memory.c As to why this only happens sporadically, we haven't been able to discover, but have found that upgrading to sys-apps/sandbox-2.1 resolved the issue. This bug is certainly a Sandbox issue.
(In reply to comment #33) > A few of us got together and really dug into this. We found out that the thread > test does perform cleanly, and would exit cleanly if it didn't get this from > Sandbox: > > Program received signal SIGSEGV, Segmentation fault. > free (ptr=0x7f15d8552008) at ../../sandbox-1.6/libsandbox/memory.c:37 > ../../sandbox-1.6/libsandbox/memory.c: No such file or directory. > in ../../sandbox-1.6/libsandbox/memory.c > > As to why this only happens sporadically, we haven't been able to discover, but > have found that upgrading to sys-apps/sandbox-2.1 resolved the issue. > > This bug is certainly a Sandbox issue. > Unmasking sandbox-2.2, upgrading, and then trying to merge postgresql-base-8.4.4-r2 works here.
On all three of my amd64 machines this issue has bitten me. All are nearly identical in how they are set up. I've run into this before with the x86 platform with 8.0 and 8.1, but not since I upgraded to 8.3 and above. In those cases it was also solved by either doing the FEATURES=-sandbox or upgrading sandbox to whatever was masked in the repo. And, like before, installing the masked sandbox-2.2 has fixed it for us. I'm not comfortable with running this later version of sandbox because I've had issues with doing that before on earlier, x86 systems. I'm sad to see it come back, honestly. This has been such a nuisance to us here where we work.
Found this thread and did FEATURES="-sandbox" emerge -u postgresql-base to get past the same problem. Don't know what will happen later on with the build, but I'll report if it fails :)
(In reply to comment #36) I had to do the same with postgresql-server to build FEATURES="-sandbox" emerge -u postgresql-server Running pgtest in #300964 yielded OK: PostgreSQL libpq is thread-safe. Interestingly enough, the same build went OK on my other amd64. Ebuild versions are postgresql-server-8.4.4-r1 and postgresql-base-8.4.4-r2
*** Bug 327531 has been marked as a duplicate of this bug. ***
*** Bug 328753 has been marked as a duplicate of this bug. ***
Same problem here for 8.4.4-r2 in stable amd64 chroot. Switching to sandbox-2.2 helps. Fact is I could need postgresql-base built with USE=threads for app-backup/bacula.
(In reply to comment #33) > > As to why this only happens sporadically, we haven't been able to discover It's because of memory corruption of the sbcontext structure with threaded apps. Using postgres' src/test/thread/thread_test.c (which is what ./configure is using), you can easily see in gdb that two threads frequently end up touching the same structure in very bad ways (uninteresting output trimmed): [Thread debugging using libthread_db enabled] [New Thread 0xb7bddb70 (LWP 14009)] [New Thread 0xb73dcb70 (LWP 14010)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7bddb70 (LWP 14009)] 0xb7c5a9c8 in realpath () from /lib/libc.so.6 (gdb) info threa 3 Thread 0xb73dcb70 (LWP 14010) 0xf57fe416 in __kernel_vsyscall () * 2 Thread 0xb7bddb70 (LWP 14009) 0xb7c5a9c8 in realpath () from /lib/libc.so.6 1 Thread 0xb7bde6c0 (LWP 14006) 0xf57fe416 in __kernel_vsyscall () (gdb) bt #0 0xb7c5a9c8 in realpath () from /lib/libc.so.6 #1 0xb7fce4fa in realpath (dirfd=-100, sb_nr=32, func=0xb7fd4b17 "unlink", file=0x804c008 "/tmp/thread_test.1.NcukEe", flags=0) from /usr/lib/libsandbox.so #2 init_env_entries (dirfd=-100, sb_nr=32, func=0xb7fd4b17 "unlink", file=0x804c008 "/tmp/thread_test.1.NcukEe", flags=0) at sandbox-1.6/libsandbox/libsandbox.c:512 #3 before_syscall (dirfd=-100, sb_nr=32, func=0xb7fd4b17 "unlink", file=0x804c008 "/tmp/thread_test.1.NcukEe", flags=0) at sandbox-1.6/libsandbox/libsandbox.c:963 (gdb) thread 3 [Switching to thread 3 (Thread 0xb73dcb70 (LWP 14010))]#0 0xf57fe416 in __kernel_vsyscall () (gdb) bt #0 0xf57fe416 in __kernel_vsyscall () #1 0xb7ced1e8 in mmap () from /lib/libc.so.6 #2 0xb7fcec91 in malloc (size=<value optimized out>) at sandbox-1.6/libsandbox/memory.c:29 #3 0xb7fd3f12 in __xmalloc (size=8, file=0xb7fd4974 "../../sandbox-1.6/libsandbox/libsandbox.c", func=0xb7fd49ec "init_env_entries", line=492) at sandbox-1.6/libsbutil/sb_memory.c:31 #4 0xb7fce377 in init_env_entries (dirfd=-100, sb_nr=32, func=0xb7fd4b17 "unlink", file=0x804c028 "/tmp/thread_test.2.VdgnYU", flags=0) at sandbox-1.6/libsandbox/libsandbox.c:492 #5 before_syscall (dirfd=-100, sb_nr=32, func=0xb7fd4b17 "unlink", file=0x804c028 "/tmp/thread_test.2.VdgnYU", flags=0) at sandbox-1.6/libsandbox/libsandbox.c:963 Notice that both threads 2 and 3 are in init_env_entries and are thus, both initializing the same sbcontext structure. The pthread_mutex_lock in before_syscall() _should_ have prevented this crash, but it was patched out because of bug #263657. Restoring the mutex to sandbox-1.6 does fix the problem described here, but it will occasionally reintroduce that annoying pause discussed in bug #263657. According to that bug, all of this was fixed in git and sandbox-1.8. Since sandbox-1.6-r2 went stable in Apr-2009, could a newer/updated/non-broken version be considered for stabilization?
I confirm this bug on an amd64 machine; upgrading to sandbox-2.2 seems to fix it.
sandbox-2.2 isnt going stable as it breaks a few other things. sandbox-2.3 however should be on a stable track. is the consensus here that: - a threaded postgresql configure test causes sandbox-1.6 to randomly segfault - sandbox-2.2+ works as expected
(In reply to comment #43) > sandbox-2.2 isnt going stable as it breaks a few other things. sandbox-2.3 > however should be on a stable track. is the consensus here that: > - a threaded postgresql configure test causes sandbox-1.6 to randomly segfault Absolutely. It's not just postgres, it's any threaded app. Postgres' tests just seem to aggravate it more. :-) sandbox-1.6 isn't thread safe. > - sandbox-2.2+ works as expected I haven't tried sandbox-2.2 (or 2.3 since it's not in the tree).
sandbox has never been thread safe in stable, so it isnt a regression. per other bug reports though, this should be fixed & stable in sandbox-2.2+.
(In reply to comment #45) > sandbox has never been thread safe in stable, so it isnt a regression. Picking nits, I'd say that it's a system regression since something that was working (building postgresql-base with USE=threads) is no longer working, but I'd agree that it's not a regression in sandbox itself (especially since sandbox hasn't changed in stable since Apr-2009). Both packages are now doing the right thing (with postgresql-base no longer just forcing threads on without testing), but the interaction between the two is broken. :-) > per > other bug reports though, this should be fixed & stable in sandbox-2.2+. I agree completely. Is there any kind of time-frame for sandbox-2.2+?
i think the issue simply has become easier to trigger rather than "always worked" and "always fails" if sandbox-2.3 doesnt cause regressions, then it'll follow the normal stable track like any other package
a quick note -- the problem still exists on dev-db/postgresql-base-8.4.4-r2 building on my x86_64 machine. The problem is that the conftest segfaults. I will attach the build log. A workaround for now seems to be: USE="-threads" emerge =dev-db/postgresql-base-8.4.4-r2
Created attachment 246010 [details] config log for thread safe test failure on x86_64
you didnt answer the question. and no one else has. assuming fixed.
(In reply to comment #48) > a quick note -- the problem still exists on dev-db/postgresql-base-8.4.4-r2 > building on my x86_64 machine. The problem is that the conftest segfaults. I > will attach the build log. > > A workaround for now seems to be: > > USE="-threads" emerge =dev-db/postgresql-base-8.4.4-r2 > That isn't a workaround to getting a thread-safe PgSQL. The workaround is to enable 'userpriv' in FEATURES, but. . . The real fix is to use sandbox2.0+. To SpanKY, yes, the consensus indicates that sandbox-2.0+ does fix this bug.
using -threads only gets the thing to compile at all. That is what I was referring to. If sandbox so be it. So, where is the updated ebuild so that I can test it on my machine? Shouldn't just build out of the box?
also, >sandbox-2.1 are all marked as unstable. If it is required then shouldn't the ebuilds reflect that requirement?
(In reply to comment #53) > also, >sandbox-2.1 are all marked as unstable. If it is required then > shouldn't the ebuilds reflect that requirement? > Only some machines have such an issue. The issue isn't consistent from one machine to the next, but happens more often on non-x86. As such, the requirement for sandbox-2.0+ only exists when the machine has this issue.
