[Debian GNUstep maintainers] Bug#1087735: gworkspace.app: NSImage(instance) does not recognize subviews

[Yavor Doganov]

Control: reassign -1 libaddressview0 0.4.8-5
Control: retitle -1 [i386] VCFViewer inspector aborts GWorkspace, making it unusable
Control: affects -1 gworkspace.app
Control: tags -1 + patch

Paul Seelig wrote:
> Looks like finally found the root cause for making GWorkspace
> malfunction on i386!

Indeed!

> There is a package named 'addresses-goodies-for-gnustep' containing
> "VCFViewer - A GWorkspace inspector for viewing .vcf files".  I had this
> package installed and apparently this pulls in libAddressView. In amd64
> this doesn't provoke GWorkspace any different, but in i386 it obviously
> does.

This is basically rarely tested code.  The upstream build system does
not build anything in the Goodies directory by default and we (we ==
Debian GNUstep team) enabled the VCFViewer inspector recently (in
0.4.8-5, uploaded 27th of September to unstable).  Excellent catch,
once again I'd like to express my gratitude for your bug report.

> Once i deinstalled 'addresses-goodies-for-gnustep' on i386, GWorkspace
> worked fine as expected.

Armed with this information, I was able to reproduce on my i386
machine.  But I get SIGSEGV and not your uncaught exception(s).  The
backtrace is:

Program received signal SIGSEGV, Segmentation fault.
0xb727a373 in objc_msg_lookup () from /lib/i386-linux-gnu/libobjc.so.4
(gdb) bt
#0  0xb727a373 in objc_msg_lookup () at /lib/i386-linux-gnu/libobjc.so.4
#1  0xafb11ef6 in -[ADPersonView calcSize]
    (self=0xafb3f4f2 <-[VCFViewer initWithFrame:inspector:]+738>, _cmd=0x5f4020) at ADPersonView.m:325
#2  0x005ec280 in  ()

This shows a corrupt stack as in your case, but it's different
(perhaps because this is a a pure bookworm system +
GNUstep/GWworkspace built from tarballs +
src:addresses-for-gnustep/0.4.8-5 with all patches applied built and
installed in the USER domain along with the rest of GNUstep core).

The code that corrupts the stack and confuses GDB is line 317 in
Framework/AddressView/ADPersonView.m:

     sizeNeeded = [[self superview] frame].size;

[self superview] returns nil for me (checked at runtime with GDB)
which leads to a garbage value and the subsequent crash.  The trouble
is that I don't understand why it happens, and why this occurs on i386
(and probably other 32-bit arches).  Fred is probably the only person
in the world who can explain this...  NSView is a fairly complex
class, and its internals have always been mystery to me.

Please test the attached patch (it solves the problem for me):

$ apt-get source addresses-for-gnustep && cd addresses-for-gnustep-*
(Make sure it's 0.4.8-5; the trixie/sid version)
$ cp /path/to/1087735.patch debian/patches
$ echo 1087735.patch >> debian/patches/series
# apt-get build-dep addresses-for-gnustep
$ dpkg-buildpackage -us -uc
# dpkg -i ../libaddressview0_0.4.8-5_i386.deb

Then start GWorkspace to test.

> Unless i am not utterly mistaken, then the debugging should probably
> rather continue with 'addresses-for-gnustep'.

That's right, I have reassigned the bug.  Many thanks for your
assistance, we are definitely getting closer to nailing this down.
-------------- next part --------------
--- addresses-for-gnustep-0.4.8.orig/Frameworks/AddressView/ADPersonView.m
+++ addresses-for-gnustep-0.4.8/Frameworks/AddressView/ADPersonView.m
@@ -312,7 +312,7 @@ static NSString *__defaultCountryCode =
   NSSize sizeNeeded;
   NSSize nvSize, nvMaxSize, nvMinSize;
 
-  if(_fillsSuperview)
+  if(_fillsSuperview && [self superview])
     {
       sizeNeeded = [[self superview] frame].size;
       if (sizeNeeded.width > 10)