| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Larry Rosenman <ler(at)lerctr(dot)org>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 2nd try @NetBSD/2.0 Alpha |
| Date: | 2005-10-18 21:58:06 |
| Message-ID: | 14208.1129672686@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Tue, Oct 18, 2005 at 04:04:42PM -0500, Larry Rosenman wrote:
>> Upped the stack to 8Mb. Now it dies in Plcheck.
> Wierd, it's dying in malloc() because the C library called kill() from
> __libc_mutex_unlock().
I wonder if this is related to the "threaded libpython doesn't work"
problem we've seen on some BSDen. Does this platform have separate
implementations of libc for threaded and unthreaded applications?
If so, and if libperl is trying to pull in a threaded libc along with
itself, maybe this is the symptom you'd see. It's reasonably probable
that this is the first call to malloc() after libperl has been loaded
into the backend ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Larry Rosenman | 2005-10-18 22:03:35 | Re: 2nd try @NetBSD/2.0 Alpha |
| Previous Message | Martijn van Oosterhout | 2005-10-18 21:45:58 | Re: 2nd try @NetBSD/2.0 Alpha |