Re: Mac OS X, PostgreSQL, PL/Tcl
От | Scott Goodwin |
---|---|
Тема | Re: Mac OS X, PostgreSQL, PL/Tcl |
Дата | |
Msg-id | 06A0C73E-658E-11D8-9272-000A95A0910A@scottg.net обсуждение исходный текст |
Ответ на | Re: Mac OS X, PostgreSQL, PL/Tcl (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Mac OS X, PostgreSQL, PL/Tcl
|
Список | pgsql-hackers |
I'll grab the CVS PG copy and try it out. Is this something the Darwin folks should be notified about? It might cause problems with other apps. thanks, /s. On Feb 22, 2004, at 4:47 PM, Tom Lane wrote: > 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 по дате отправления: