bug#620: #620 - 23.0.60; Bootstrapping with the GNUstep port impossible - Emacs bug report logs

[Yavor Doganov]

clone 620 -1
retitle -1 Segfaults in alloc.c within gdb on gNewSense
thanks

(Please merge back the bug if it turns out to be the same issue.)

Glenn Morris wrote:
> 
> So far, the segfaults are always in alloc.c, mostly in mark_object
> at line 5540 or 5434, but once in mark_interval at 1508.

Oddly enough, these are almost equivalent to the problems I see
(unrelated to bootstrapping) under gNewSense DeltaH (Base 1.14.1, GUI
0.12.0).  I was about to report the problem separately, after more
investigation.

On gNewSense with GNOME (with the default Metacity WM), I basically
experience the same behaviour as described in #984.

Under Window Maker and the GNUstep art backend, Emacs starts, the
frame is drawn and I can perform some basic operations.  (There are
other major issues, but let's leave them out for now.)

If I open xterm and start Emacs from within gdb, it always crashes
(under both GNUstep backends) with a backtrace very similar (if not
equivalent) to the ones Glenn posted.

Now the odd: If under wmaker I start Emacs 22.3, and from there start
Emacs.app either with M-x gdb or M-x shell; gdb ..., I get the same
backtrace as in #984.

I should probably mention that gnustep-back has fairly complicated WM
management code, and support for all window managers in the wild is
not guaranteed.  However, applications should not crash if they're run
under a poorly supported WM (Window Maker is the best supported, and
Metacity is claimed to be supported).  Personally, I was surprised to
see Emacs.app crashing under GNOME while running under wmaker.  All
other GNUstep apps run fine under GNOME.  It is either a subtle bug in
Emacs.app, or a bug in GNUstep that is exposed by a complex app such
as Emacs.

Hopefully I'll followup with more details to the cloned bug as soon as
I figure out the logic behind all of this weirdness.