Thread: checking on buildfarm member thrush
I'm trying to determine why thrush has been failing on PG CVS HEAD for the past few days. Could you try running the attached program on that machine, and see what it prints? I suspect it will dump core :-( Note: you might need to use -D_GNU_SOURCE to get it to compile at all. regards, tom lane #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <fcntl.h> int main() {if (posix_fadvise(fileno(stdin), 0, 0, POSIX_FADV_DONTNEED)) printf("failed: %s\n", strerror(errno));else printf("OK\n");return0; }
Tom Lane wrote: > I'm trying to determine why thrush has been failing on PG CVS HEAD for > the past few days. Could you try running the attached program on that > machine, and see what it prints? I suspect it will dump core :-( > > Note: you might need to use -D_GNU_SOURCE to get it to compile at all. > > regards, tom lane > > > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <errno.h> > #include <fcntl.h> > > int > main() > { > if (posix_fadvise(fileno(stdin), 0, 0, POSIX_FADV_DONTNEED)) > printf("failed: %s\n", strerror(errno)); > else > printf("OK\n"); > return 0; > } > $ gcc -D_GNU_SOURCE tom.c -o tom $ ./tom failed: Success Regards Gaetano Mendola
Gaetano Mendola <mendola@bigfoot.com> writes: > Tom Lane wrote: >> I'm trying to determine why thrush has been failing on PG CVS HEAD for >> the past few days. Could you try running the attached program on that >> machine, and see what it prints? I suspect it will dump core :-( > $ gcc -D_GNU_SOURCE tom.c -o tom > $ ./tom > failed: Success Hmph. Well, that destroys the posix_fadvise-dumps-core theory, and leaves us still wondering why thrush is failing "make check". There's been a core dump recently introduced *somewhere*: NOTICE: type reference hobbies_r.person%TYPE converted to text LOG: server process (PID 2818) was terminated by signal 11 LOG: terminating any other active server processes Could you get a gdb stack trace from that crash? If the buildfarm run is under a suitable ulimit, it should be leaving a core file in the test PGDATA directory. regards, tom lane
Tom Lane wrote: > Could you get a gdb stack trace from that crash? If the buildfarm > run is under a suitable ulimit, it should be leaving a core file > in the test PGDATA directory. Unfortunately the core size for the user pgfarm is 0: $ulimit -c 0 However I did a configure, make and make check on regression test and I got two cores, may be I do something wrong but I'm not able to get any information. Configured with: ./configure --prefix=/home/pgfarm/HEAD/inst --enable-cassert --enable-debug --enable-nls --enable-integer-datetimes --with-perl--with-python --with-tcl $ gdb tmp_check/install/home/pgfarm/HEAD/inst/bin/postgres ./tmp_check/data/core.6516 GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". warning: core file may not match specified executable file. Core was generated by `postgres: pgfarm regression [local] COMMENT '. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 0x00000005 in ?? () (gdb) bt #0 0x00000005 in ?? () #1 0x00004000 in ?? () anything else I can do ?