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

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@debis.com (Jan Wieck)
Subject:            Re: [ADMIN] Running Postgres on a HP-Ux 10.10 System
To:                 nippes@mail.ums-ulm.de
Date sent:          Wed, 27 Jan 1999 15:15:05 +0100 (MET)
Copies to:          wieck@debis.com, pgsql-admin@postgreSQL.org
Send reply to:      jwieck@debis.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@debis.com (Jan Wieck) #