Re: Mac OS X, PostgreSQL, PL/Tcl - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Mac OS X, PostgreSQL, PL/Tcl
Date
Msg-id 18820.1077486476@sss.pgh.pa.us
Whole thread Raw
In response to Re: Mac OS X, PostgreSQL, PL/Tcl  (Scott Goodwin <scott@scottg.net>)
Responses Re: Mac OS X, PostgreSQL, PL/Tcl  (Scott Goodwin <scott@scottg.net>)
List pgsql-hackers
Scott Goodwin <scott@scottg.net> writes:
> Found the problem. If I have a very long environment variable exported  
> and I start PG, PG crashes when I try to load PG/Tcl. In my case I use  
> color ls and I have a very long LS_COLORS environment variable set.

I was able to duplicate this.  I am not entirely sure why the problem is
dependent on the environment size, but I now know what causes it.
It seems Darwin's libc keeps its own copy of the argv pointer, and when
we move argv and then scribble on the original, it causes problems for
subsequent code that tries to look at argv[0] to determine the
executable's location.  (It's a good thing Darwin is open source, 'cause
I'm not sure we'd have ever seen the connection if we hadn't been able
to look at the source code for their libc.)

The fix is basically

+ #if defined(__darwin__)
+ #include <crt_externs.h>
+ #endif

+ #if defined(__darwin__)
+         *_NSGetArgv() = new_argv;
+ #endif

which you can stick into main.c if you need a workaround.  I applied a
more extensive patch to HEAD that refactors this code into ps_status.c,
but I'm disinclined to apply that patch to stable branches...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Pl/Java - next step?
Next
From: Tom Lane
Date:
Subject: Heads up: 7.3.6 and 7.4.2 coming soon