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 have duplicated the problem by renaming my .bashrc and logging back
in. With this clean environment, I started PG and loaded PG/Tcl without
any problems. I then created the following environment variable on the
command line:

LONG_VAR=aaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbb:cc cccccccccccccccc:
ddddddddddddddddddd:eeeeeeeeeeeeeeeeeee:ffffffffff fffff:
ggggggggggggggggg:hhhhhhhhhhhhhhhhhhhh:iiiiiiiiiii iiiiiiii:
jjjjjjjjjjjjjjjjjjjjj:kkkkkkkkkkkkkkkkkkkkkk:lllll lllllllllllllll:
mmmmmmmmmmmmmmmmmmmmmmm:nnnnnnnnnnnnnnnnnnnnnnnnn:
oooooooooooooooooooooooppppppppppppppppppppp:qqq qqqqqqqqqqqqqqqqqqqq:
rrrrrrrrrrrrrrrrrrrrrrr:ssssssssssssssssssssssssss :
ttttttttttttttttttttttttttt:uuuuuuuuuuuuuuuuuuuuuu uuu:
vvvvvvvvvvvvvvvvvvvvvv:wwwwwwwwwwwwwwwwwwwwwwwwwww www:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:yyyyyyyyyyyyyy yyyyyyyyyyyyyyy:
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

and exported it. (Obviously the line above is going to be broken into
multiple lines by the mailer...).

Then I stopped and restarted PG, loaded PG/Tcl and PG crashed. You
*must* stop and restart PG for the problem to exhibit itself, otherwise
it won't pick up the change in the environment. I suspect I'm running
into a buffer overflow situation.

Ok, it fails consistently when LONG_VAR is 523 characters or greater;
works consistently when LONG_VAR is 522 characters or smaller. Might
not fail at the same number for others.

/s.




To prove that this was the problem, I cleaned out my environment by
moving my .bashrc file to another name, logged out, logged in, start
On Feb 21, 2004, at 1:51 AM, Tom Lane wrote:


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Scott Goodwin <scott (AT) scottg (DOT) net> writes:
Interesting. Did you check whether the limiting factor is the longest
variable length, or the total size of the environment? ("env|wc" would
probably do as an approximation for the latter.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

I'm certain that the length of a single env var is the only factor
involved, and not the size of the enviroment itself. If I login to my
normal environment and unset LS_COLORS, everything works fine. If I
move my .bashrc out of the way, login fresh and create an env var > 522
chars, it fails. My login environment is much larger than the
environment I get without . bashrc, and the results of setting a single
env var to > 522 chars duplicates the problem in both envs. leading me
to believe that env size doesn't have an effect on this problem. I've
now set my PG startup script to 'unset LS_COLORS' before starting PG,
and this works great. Has anyone else tried to duplicate this problem?
I'm using Mac OS 10.3.2, PG 7.4.1, Tcl 8.4.5.

/s.


On Feb 22, 2004, at 12:21 PM, Tom Lane wrote:


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Scott Goodwin <scott (AT) scottg (DOT) net> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

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:


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Scott Goodwin <scott (AT) scottg (DOT) net> writes:
It's unlikely that they'll consider it their problem.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org