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");
return 0;
}
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 ?