Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
On Tue, Oct 18, 2005 at 10:07:26PM -0500, Larry Rosenman wrote: ...or attach with a debugger like gdb. d'oh. I go stupid occasionally :) If someone wants me to, I can try that. Yes, actually. See, its dying in the seg test already with: -- Open intervals SELECT '0..'::seg AS seg; ! ERROR: floating-point exception ! DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, s uch as division by zero. SELECT '0...'::seg AS seg; ! ERROR: floating-point exception ! DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, s uch as division by zero. You need to attach a debugger to find out where that error is actually happenening. Just startup the backend, connect to it and connect gdb to the newly spawned backend and just run that query by hand. Then you should get the backtrace at SIGFPE. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgp437RUDPiCT.pgp Description: PGP signature
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
Martijn van Oosterhout wrote: On Tue, Oct 18, 2005 at 10:07:26PM -0500, Larry Rosenman wrote: ...or attach with a debugger like gdb. d'oh. I go stupid occasionally :) If someone wants me to, I can try that. Yes, actually. See, its dying in the seg test already with: -- Open intervals SELECT '0..'::seg AS seg; ! ERROR: floating-point exception ! DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, s uch as division by zero. SELECT '0...'::seg AS seg; ! ERROR: floating-point exception ! DETAIL: An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, s uch as division by zero. You need to attach a debugger to find out where that error is actually happenening. Just startup the backend, connect to it and connect gdb to the newly spawned backend and just run that query by hand. Then you should get the backtrace at SIGFPE. I don't have the time today (need to do some paying work). However, If someone wants, I can pass an ID/PW along so that they May find it. (or it can wait till the weekend). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: On Tue, Oct 18, 2005 at 04:04:42PM -0500, Larry Rosenman wrote: Upped the stack to 8Mb. Now it dies in Plcheck. Wierd, it's dying in malloc() because the C library called kill() from __libc_mutex_unlock(). I wonder if this is related to the threaded libpython doesn't work problem we've seen on some BSDen. Does this platform have separate implementations of libc for threaded and unthreaded applications? If so, and if libperl is trying to pull in a threaded libc along with itself, maybe this is the symptom you'd see. It's reasonably probable that this is the first call to malloc() after libperl has been loaded into the backend ... regards, tom lane Doesn't appear to have a separate libc, HOWEVER, -lpthread may be screwing us: $ ldd perl perl: -lm.0 = /usr/lib/libm.so.0 -lcrypt.0 = /usr/lib/libcrypt.so.0 -lpthread.0 = /usr/lib/libpthread.so.0 -lperl = /usr/pkg/lib/perl5/5.8.0/alpha-netbsd-thread-multi/CORE/libperl.so -lc.12 = /usr/lib/libc.so.12 $ I'm not the machines owner, but I can ask if we can get a NON-threaded PERL. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
Martijn van Oosterhout kleptog@svana.org writes: On Tue, Oct 18, 2005 at 04:04:42PM -0500, Larry Rosenman wrote: Upped the stack to 8Mb. Now it dies in Plcheck. Wierd, it's dying in malloc() because the C library called kill() from __libc_mutex_unlock(). I wonder if this is related to the threaded libpython doesn't work problem we've seen on some BSDen. Does this platform have separate implementations of libc for threaded and unthreaded applications? If so, and if libperl is trying to pull in a threaded libc along with itself, maybe this is the symptom you'd see. It's reasonably probable that this is the first call to malloc() after libperl has been loaded into the backend ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
On Tue, Oct 18, 2005 at 04:04:42PM -0500, Larry Rosenman wrote: Upped the stack to 8Mb. Now it dies in Plcheck. Logs/bt.out in: http://www.lerctr.org/~ler/alphadeath2.tar.gz Wierd, it's dying in malloc() because the C library called kill() from __libc_mutex_unlock(). You're not the only one though: http://archive.netbsd.se/?ml=netbsd-usersa=2004-01m=18027 No-one answered that one either... -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgp2iUhqV0cV1.pgp Description: PGP signature
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
I think in this case you need to try to install the PL manually and see what happens - run psql, attach the debugger to the backend, and issue create language plperl ... Having it die at this stage is rather strange. cheers andrew Larry Rosenman wrote: Upped the stack to 8Mb. Now it dies in Plcheck. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
On Oct 18, 2005, at 5:11 PM, Martijn van Oosterhout wrote: On Tue, Oct 18, 2005 at 05:03:35PM -0500, Larry Rosenman wrote: Doesn't appear to have a separate libc, HOWEVER, -lpthread may be screwing us: snip If it is that, does it work if you compile postgres with -lpthread. Sure, we don't use the functions but maybe it's a prerequisite to be able to dlopen() thread libs. Should be quicker to test, just rerun the final link command by hand with the extra option... I added a LIBS += -lpthread to the end of src/makefiles/ Makefile.netbsd and got a LOOP on the make check :( More ideas? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-351-4152 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 PGP.sig Description: This is a digitally signed message part
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
On Oct 18, 2005, at 8:49 PM, Larry Rosenman wrote: On Oct 18, 2005, at 5:11 PM, Martijn van Oosterhout wrote: On Tue, Oct 18, 2005 at 05:03:35PM -0500, Larry Rosenman wrote: Doesn't appear to have a separate libc, HOWEVER, -lpthread may be screwing us: snip If it is that, does it work if you compile postgres with -lpthread. Sure, we don't use the functions but maybe it's a prerequisite to be able to dlopen() thread libs. Should be quicker to test, just rerun the final link command by hand with the extra option... I added a LIBS += -lpthread to the end of src/makefiles/ Makefile.netbsd and got a LOOP on the make check :( More ideas? LER I've removed the --with-perl from the config for now, and am re- running it yet again :) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-351-4152 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 PGP.sig Description: This is a digitally signed message part
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
Larry Rosenman ler@lerctr.org writes: I added a LIBS += -lpthread to the end of src/makefiles/ Makefile.netbsd and got a LOOP on the make check :( Er ... define LOOP? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
On Oct 18, 2005, at 9:39 PM, Tom Lane wrote: Larry Rosenman ler@lerctr.org writes: I added a LIBS += -lpthread to the end of src/makefiles/ Makefile.netbsd and got a LOOP on the make check :( Er ... define LOOP? postgres master process sitting with 98%+ cpu for 1hour and NO progress being made. I could not find a truss/strace binary on the box :( regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-351-4152 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
On Tue, Oct 18, 2005 at 09:41:21PM -0500, Larry Rosenman wrote: I could not find a truss/strace binary on the box :( In BSD land try ktrace. -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 2nd try @NetBSD/2.0 Alpha
On Oct 18, 2005, at 10:03 PM, Michael Fuhr wrote: On Tue, Oct 18, 2005 at 08:59:23PM -0600, Michael Fuhr wrote: On Tue, Oct 18, 2005 at 09:41:21PM -0500, Larry Rosenman wrote: I could not find a truss/strace binary on the box :( In BSD land try ktrace. ...or attach with a debugger like gdb. d'oh. I go stupid occasionally :) If someone wants me to, I can try that. As to the without perl build, it dies in contribcheck. Logs in: http://www.lerctr.org/~ler/alphacontribdeath.tar.gz $ tar tzvf alphacontribdeath.tar.gz drwxr-xr-x 2 ler users 0 Oct 18 22:00 lastrun-logs -rw-r--r-- 1 ler users 22708 Oct 18 21:25 lastrun-logs/ CVS.log -rw-r--r-- 1 ler users 11453 Oct 18 21:29 lastrun-logs/ configure.log -rw-r--r-- 1 ler users 227987 Oct 18 21:29 lastrun-logs/ config.log -rw-r--r-- 1 ler users 154407 Oct 18 21:47 lastrun-logs/ make.log -rw-r--r-- 1 ler users 201363 Oct 18 21:50 lastrun-logs/ check.log -rw-r--r-- 1 ler users 40733 Oct 18 21:54 lastrun-logs/ make-contrib.log -rw-r--r-- 1 ler users 49358 Oct 18 21:54 lastrun-logs/ make-install.log -rw-r--r-- 1 ler users 1531 Oct 18 21:55 lastrun-logs/ initdb.log -rw-r--r-- 1 ler users 60 Oct 18 21:55 lastrun-logs/ startdb-1.log -rw-r--r-- 1 ler users 128491 Oct 18 21:57 lastrun-logs/ install-check.log -rw-r--r-- 1 ler users 65 Oct 18 21:57 lastrun-logs/ stopdb-1.log -rw-r--r-- 1 ler users 60 Oct 18 21:57 lastrun-logs/ startdb-2.log -rw-r--r-- 1 ler users711 Oct 18 21:57 lastrun-logs/pl- install-check.log -rw-r--r-- 1 ler users 64 Oct 18 21:57 lastrun-logs/ stopdb-2.log -rw-r--r-- 1 ler users 60 Oct 18 21:57 lastrun-logs/ startdb-3.log -rw-r--r-- 1 ler users 18425 Oct 18 21:57 lastrun-logs/ install-contrib.log -rw-r--r-- 1 ler users 41443 Oct 18 22:00 lastrun-logs/ contrib-install-check.log -rw-r--r-- 1 ler users 45714 Oct 18 22:00 lastrun-logs/web- txn.data tar: ustar vol 1, 19 files, 962560 bytes read, 0 bytes written in 1 secs (962560 bytes/sec) $ -- Michael Fuhr -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-351-4152 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
