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