Summary: [NSMiniWindowView setImage] crashes with nil as
Submitted by: cc_benny
Submitted on: Sun 23 Oct 2016 07:09:55 PM GMT
Severity: 3 - Normal
Item Group: Bug
Assigned to: None
Discussion Lock: Any
Current GNUStep builds of Emacs sometimes crash when minimizing, because they
set the miniImage to nil. According to comments in the Emacs code, nil is
supoosed to trigger some default handling on Mac OS X. On GNUStep though,
[NSMiniWindowView setImage] calls [imgCopy size] in NSWindow.m line 578, which
crashes if imgCopy is nil.
Please advise if this is should rather be fixed/worked-around in Emacs. Also,
if this is going to be fixed in GNUStep, can you think of some runtime-test
for this, so that Emacs does not have to disable that feature on GNUStep
generally, while the bug is out there in the OS distributions?
I just applied a tiny patch that should fix this issue. You should try this
code with the SVN version of GNUstep. The problem you did get was with a
method that returns a structure being sen to a nil object. On most
architectures this gets handled correctly by the Objective-C runtime but it
may cause a segmentation fault on Sparc and other special hardware.
This change will be included in the next release of GNustep gui. I don't know
when this will happen but the version will be 0.26. This should be visible in
the library version but I am not aware of any runtime check for it. For
historical reasons base and gui are no Frameworks and this makes reporting a
version number harder.
I just applied your fix to 0.24, the current on the Debian jessie where I am
testing. This fixes the problem, thank you.
I also tried building a current GNUstep and build/link against that, but on
start I get a message box, saying "NSInternalInconsistencyException: NSApp's
run called recursively". Is that a known symptom? Where to I set breakpoint
to catch this in a gdb?
> On most architectures this gets handled correctly by the
> Objective-C runtime but it may cause a segmentation fault
> on Sparc and other special hardware
This is on i686, so not really exotic ;-). When I replicate the code in
question in a simple test program, I can not reproduce the problem. I'm
attaching some gdb output from the original crash, in case that helps.
We link against a specific version of the libs anyway, so we can just use
compile-time checks bad on GNUSTEP_GUI_MAJOR_VERSION and
GNUSTEP_GUI_MINOR_VERSION. I see that this is already done in another place.