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) #
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 |