Re: [HACKERS] FreeBSD problem under heavy load

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] FreeBSD problem under heavy load
Date: 1999-12-10 06:58:06
Message-ID: 17219.944809086@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> The current status string is copied into old_status, then the pointer
> to it is set to a gloable variable ps_status by PS_SET_STATUS
> macro. Unfortunately old_status is on the stack, so once WaitOnLock
> returns, ps_status would point to a garbage. In the subsequent call to
> WaitOnLock,

> strcpy(old_status, PS_STATUS);

> will copy garbage string into old_status. So if the string is longer
> than 63, the stack would be broken. Note that this would not happen on
> Linux due to the difference of the definition of the macro. See
> include/utils/ps_status.h for more details.

Ugh. It wouldn't happen on HPUX either, because the PS_STATUS stuff
all compiles as no-ops here. So that's why I couldn't see it.

You didn't say what you had in mind to fix this, but I think the safest
approach would be to reserve an area to copy the PS_SET_STATUS string
into on *all* systems. Otherwise we'll just get bitten by this kind of
bug again in future.

> BTW, I think pgbench is usefull to detect this kind of problems. Can I
> put it into contrib or somewhere?

Sounds like a good idea to me.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 1999-12-10 07:08:50 Re: [HACKERS] 6.6 release
Previous Message The Hermit Hacker 1999-12-10 06:55:18 Re: [HACKERS] 6.6 release