bug#1079: GNUstep port segfaults making autoloads on x86_64

[Adrian Robert <adrian.b.robert@gmail.com>]

On Oct 4, 2008, at 9:40 PM, Glenn Morris wrote:

> Adrian Robert wrote:
>
>> #ifndef CANNOT_DUMP
>>  if (initialized)
>> #endif
>>    ns_init_paths ();
>> #endif
>>
>> Hmm, not sure if this ns_init_paths() is needed during the bootstrap
>
> I tried commenting it out; then I get a segfault loading
> term/ns-win.el from the ns-list-colors call.
>
>> -- i.e., should the conditional be different, or should it be moved   
>> after the init_...() calls?  Unf I cannot test this stuff myself.
>
> I tried (randomly) moving it after init_cmdargs; didn't make a
> difference.
>
> Since it works (for this stage at least) on 32-bit, but not 64, I
> don't think something like that can be the answer.
>
> It's the very first line of ns_init_paths that is the problem, does
> this suggest anything?
>
> NSBundle *bundle = [NSBundle mainBundle];

It's just an ordinary API call, but it's not meant to be run from an  
app that is not inside a "bundle".  That is, once packaged into  
Emacs.app directory structure, it's OK to run this call, but the  
behavior would be undefined if just being run as src/[t]emacs.  From  
your stack trace it looked like GNUstep tried to initialize some of  
its internals and ran into an unexpected condition causing the crash.

So, if there were some way to run ns_init_paths() only in either  
dumped emacs, or CANNOT_DUMP emacs but NOT during bootstrapping, I  
think that would be best.

(I may not have fully thought this through when I first wrote that  
conditional, probably since the ns_init_paths impl originally didn't  
call -mainBundle.)

As for the location before or after init_ calls, on second thought I'm  
not sure this matters a lot.  I believe I put it the same place the  
Carbon port had its equivalent call.

Regarding the later segfault after commenting out, ns_init_paths only  
sets environment variables affecting emacs lisp load paths, does not  
initialize anything else.  So I'd say this is a separate bug.