bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#1079: GNUstep port segfaults making autoloads on x86_64


From: Adrian Robert
Subject: bug#1079: GNUstep port segfaults making autoloads on x86_64
Date: Sat, 4 Oct 2008 22:06:54 -0400


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.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]