Обсуждение: abnormal exits: what am I overlooking?

Hi,

I'm doing some tests with 7.2 here, and I'm having trouble creating a
table.  This is on Solaris 7 compiled with a 64 bit gcc; gcc -v gives

Reading specs from
/opt/OXRS/local/gcc-3.0-v9/lib/gcc-lib/sparcv9-sun-solaris2/3.0.3/specs
Configured with: ./configure --prefix=/opt/OXRS/local/gcc-3.0-v9
--enable-languages=c,c++ sparcv9-sun-solaris2 : (reconfigured)
./configure --prefix=/opt/OXRS/local/gcc-3.0-v9
--enable-languages=c,c++ --host=sparcv9-sun-solaris2 : (reconfigured)
./configure --prefix=/opt/OXRS/local/gcc-3.0-v9
--enable-languages=c,c++ --host=sparcv9-sun-solaris2
Thread model: posix
gcc version 3.0.3

Postgres passwd all its regression tests after the build.

Here's the CREATE statement:

create table epp_registrar_notification
(id integer primary key default nextval('registrar_notification_id_seq'),
registrar_id integer,
created_on timestamp default current_timestamp,
message_type char(1),
poll_status char(1),
email_status char (1),
send_to_email varchar,
copy_to_email varchar,
from_email varchar,
subject_line varchar,
message_text varchar,
expires_on timestamp not null default current_times tamp + '7 days');

The backend died with the attached in the log, debug level 1.  There
was _once_ a message returned to psql, but in repeated attempts, I
haven't been able to see it again, and I didn't catch it the first
time.  It was a message talking about allocation, I think, but I know
that's no help :( .

So, I thought I'd try turning up the debug level.  When I turn it
to 4, the system stops responding when I try to connect.  Hmm.  So I
try with debug level 3.  I can connect, but when I try to run the
query, it locks.  Here's the end of the log:

2002-02-27 19:54:23 [28780]  NOTICE:  CREATE TABLE / PRIMARY KEY will
create implicit index 'epp_registrar_notification_pkey' for table
'epp_registrar_notification'
2002-02-27 19:54:23 [28780]  DEBUG:  parse tree:
2002-02-27 19:57:59 [28803]      DEBUG:  proc_exit(0)
2002-02-27 19:57:59 [28803]  DEBUG:  shmem_exit(0)
2002-02-27 19:57:59 [28803]  DEBUG:  exit(0)
2002-02-27 19:57:59 [28773]  DEBUG:  reaping dead processes
2002-02-27 19:57:59 [28773]  DEBUG:  child process (pid 28803) exited
with exit code 0

Anyone have any idea what I ought to be looking at next?  Am I just
overlooking something obvious?

A

--
----
Andrew Sullivan                               87 Mowat Avenue
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110

Andrew Sullivan <andrew@libertyrms.info> writes:
> I'm doing some tests with 7.2 here, and I'm having trouble creating a
> table.  This is on Solaris 7 compiled with a 64 bit gcc; gcc -v gives

> The backend died with the attached in the log, debug level 1.

> 2002-02-27 18:40:36 [25234]  DEBUG:  server process (pid 27450) was terminated by signal 10

Looks like a core dump.  What's signal 10 on your machine?
(/usr/include/signal.h is a good reference if you don't know)
Can you get a gdb backtrace from the core file?

            regards, tom lane

On Wed, Feb 27, 2002 at 06:39:47PM -0500, Tom Lane wrote:
> Andrew Sullivan <andrew@libertyrms.info> writes:
> > I'm doing some tests with 7.2 here, and I'm having trouble creating a
> > table.  This is on Solaris 7 compiled with a 64 bit gcc; gcc -v gives

> Can you get a gdb backtrace from the core file?

Tom very kindly stepped in and had a poke around with a debugger (and
had to use -- eek -- adb because there was some sort of argument
between gdb compiled as 64 bit and Solaris), and discovered that
vsnprintf was doing something nasty.

Turns out, according to the GNU autoconf pages (at
<http://www.dis.com/gnu/autoconf/autoconf_45.html#SEC45>), that
vsnprintf overruns the buffer sometimes.

The answer is to edit src/backend/port/Makefile and add "snprintf.o"
to OBJS.  Postgres includes its own implementation for platforms that
don't have it.

Thanks to Tom Lane.

A

--
----
Andrew Sullivan                               87 Mowat Avenue
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110

Andrew Sullivan <andrew@libertyrms.info> writes:
> [ 64-bit build on Solaris 7 fails ]

> The answer is to edit src/backend/port/Makefile and add "snprintf.o"
> to OBJS.

While updating FAQ_Solaris I realized that the above is not sufficient:
it will cause the backend to include the corrected vsnprintf(), but the
client libraries and utilities need it too.  So you need to also change
src/Makefile.global.  I've added the following entry to FAQ_Solaris:

----------
5) Why does my 64-bit build sometimes crash?

On Solaris 7 and older, the 64-bit version of libc has a buggy vsnprintf
routine, which leads to erratic core dumps in PostgreSQL.  The simplest known
workaround is to force PostgreSQL to use its own version of vsnprintf rather
than the library copy.  To do this, after you run 'configure' edit two files
produced by configure:

(1) In src/Makefile.global, change the line
    SNPRINTF =
to read
    SNPRINTF = snprintf.o

(2) In src/backend/port/Makefile, add "snprintf.o" to OBJS.  (Skip this
step if you see "$(SNPRINTF)" already listed in OBJS.)

Then build as usual.
----------

(The parenthetical remark is because I've fixed current sources so that
the port makefile won't need to be edited separately.  But in 7.2 you
need to hit both files.)

            regards, tom lane