On Nov 8, 2003, at 1:13 PM, Tom Lane wrote:
> Bob Ippolito <bob@redivi.com> writes:
>> On Nov 8, 2003, at 12:31 AM, Tom Lane wrote:
>>> I have just in the past couple hours realized that ps_status.c is
>>> seriously broken on OS X 10.3.
>
>> Er... I meant memcmp.. Have you tried removing the system.c hack?
>> That's what fixed it for me.
>
> AFAICT system.c hasn't got anything to do with the problem that I'm
> seeing; it's purely a matter of ps_status.c clobbering argv[] contents
> that the dynamic loader depends on for some weird reason. It looks
> like Apple's implementation stores a copy of the original argc count,
> and there is a bit of code in the loader that for some reason is
> examining each argv string from 0..original_argc-1. Who knows why :-(
> ... but where we set save_argv[1] to NULL, we create a null pointer
> crash in the loader. Take that out, no crash. You would not see this
> crash if you started the postmaster with no command-line arguments,
> btw.
>
> I'm planning to change ps_status so that instead of zeroing
> save_argv[1], it makes all the original argv strings be pointers to ""
> except for argv[0].
It may be causing problems because dyld does this thing called
@executable_path substitution so it can find dylibs relative to the
executable. Also, the WindowServer and several other things
(CoreFoundation, Foundation) use argv[0] to determine whether the
executable is inside a bundle or not.
I don't think OS X people would make a big fuss about argv[0] not being
as useful as it is on other platforms, personally I'd just take it out
if it's not working.
> As for getting rid of system.c, I am not eager to do that since it
> would
> certainly break compatibility with OS X 10.1. We could conditionally
> compile it out perhaps. Do you know what #define symbol we could test
> for to determine which OS X version we are on?
See /usr/include/AvailabilityMacros.h
-bob