(Fwd) Re: [ADMIN] Running Postgres on a HP-Ux 10.10 System

From: "Reiner Nippes" <nippes(at)ums-ulm(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: (Fwd) Re: [ADMIN] Running Postgres on a HP-Ux 10.10 System
Date: 1999-01-28 14:22:30
Message-ID: 199901281419.JAA55450@hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi everybody,

I found a problem running Postgres 6.4 and 6.4.2 on our HP-Ux
10.10 system. (Compiling with gcc 2.7.1.3 or gcc 2.8.1 makes no
differences.)

After two SQL errors (e.g. SALACT instead of SELECT or insert
something into a none existing table) the backend dies abnormally.

Below the HP-Ux gurus can find additional information from the
core file.

Any help welcome.

Kind regards,
Reiner Nippes

UMS GmbH, Ulm - Germany

------- Forwarded Message Follows -------
From: jwieck(at)debis(dot)com (Jan Wieck)
Subject: Re: [ADMIN] Running Postgres on a HP-Ux 10.10 System
To: nippes(at)mail(dot)ums-ulm(dot)de
Date sent: Wed, 27 Jan 1999 15:15:05 +0100 (MET)
Copies to: wieck(at)debis(dot)com, pgsql-admin(at)postgreSQL(dot)org
Send reply to: jwieck(at)debis(dot)com (Jan Wieck)

> #0 0xc00a9098 in memset ()
> (gdb) backtrace
> #0 0xc00a9098 in memset ()
> #1 0x15d0e8 in PostgresMain (argc=-534762622, argv=0x203cb000,
> real_argc=-534763790, real_argv=0x203cb000) at postgres.c:1582
> #2 0xe0202530 in ?? ()
> Cannot access memory at address 0x203cafe8.
>
> (gdb) frame 1
> #1 0x15d0e8 in PostgresMain (argc=-534762622, argv=0x203cb000,
> real_argc=-534763790, real_argv=0x203cb000) at postgres.c:1582
> 1582 MemSet(parser_input, 0, MAX_PARSE_BUFFER);
> (gdb) list
> 1577
> 1578 /* ----------------
> 1579 * (3) read a command.
> 1580 * ----------------
> 1581 */
> 1582 MemSet(parser_input, 0, MAX_PARSE_BUFFER);
> 1583
> 1584 firstchar = ReadCommand(parser_input);
> 1585
> 1586 QueryCancel = false; /* forget any earlier CANCEL sig
> nal */
> (gdb)

Bingo!

MemSet() is a macro in src/include/c.h which in this case
calls the real memset() library function (area to set is
greater than 64 bytes).

parser_input is a dynamic char array inside of
PostgresMain(), so it's part of the innermost stackframe.
This looks to me like the execution of longjmp() from the
elog() corrupted the stackframe of PostgresMain() instead of
restoring it as it should have done.

There are different kinds of jumps used depending on the
installation. One is setjmp()/longjmp() the other is
sigsetjmp()/siglongjmp(). If I recall correct, sigsetjmp() is
#defined to setjmp() if it isn't available.

So folks, low level HP/UX 10.10 know how required!

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-01-28 14:37:03 Re: [HACKERS] Bug or feature? COPY ignores column defaults
Previous Message Vadim Mikheev 1999-01-28 14:11:51 Re: [HACKERS] Bug or feature? COPY ignores column defaults