Processed: Re: Bug#1087735: gworkspace.app: NSImage(instance) does not recognize subviews

[Debian Bug Tracking System]

severity -1 grave

Bug #1087735 [gworkspace.app] gworkspace.app: NSImage(instance) does not recognize subviews
Severity set to 'grave' from 'important'

tags -1 + moreinfo

Bug #1087735 [gworkspace.app] gworkspace.app: NSImage(instance) does not recognize subviews
Added tag(s) moreinfo.

[Riccardo Mottola]

Hello Paul,

is the issue reproducible on a system you have on where you can get a
stacktrace?

I just tested on my Linux i386 laptop running Devuan with GCC runtime
(all source being GIT and compiled by myself, no packages) and I have no
issues with GWorkspace. So no immediate i386 32bit issue (which would be
also strange).

Thus we must understand what is happening at your place.
First thing I see is that the screenshot shows a different exception
than the one you describe. NSConstantString vs NSImage. Why? is it
random? or a different compilation run? This is probably a memory issue
somewhere.

We need a stacktrace.

We need to know how gnustep core and gworkspace is compiled. Do you have
PDFKit installed and is it enabled? did you enable GWMetadata?

Please open an issue on github for gworkspace for it if you want to
collaborate on this, so we can exhange discussion. It might be a core
bug or GWorkspace bug or a configuration problem.

Riccardo

Package: gworkspace.app
Version: 1.0.0-4
Severity: important
Tags: upstream
Hello all,
the current gworkspace.app application for trixie/i386 shows following error
"Uncaught exception NSInvalidArgumentException, reason: NSImage(instance) does
not recognize subviews"
and only leaves the option to "Abort" the application.
A screenshot is available at
Loading Image... for a visual depiction
of the error message.
Running the same application version in both amd64 and arm64 doesn't show any
errors and works normally. So this issue appears to be limited to the i386
variant only.
Checking out and recompiling the current upstream sources from
https://github.com/gnustep/apps-gworkspace produces the same issue under i386.
Please let me know if need me to provide more information.
Thanks for maintaining this package!
Regards,
Paul

[Riccardo Mottola]

Hi,

FWIW, I also cannot reproduce on i386, but this is on a bookworm
machine with manually built latest GNUstep + GWorkspace from tarballs;
GCC 12.2.0. The OP reports the bug on trixie, GCC 14.2.0.

I use Devuan and also have 12.2 compiler, so I think we are matched here.
On another system (64bit though) I do use gcc 14 without issues.
But a lot of other dependencies might be updated. Read below.

Post by Riccardo Mottola
First thing I see is that the screenshot shows a different exception
than the one you describe. NSConstantString vs NSImage.

I also noticed this.

Paul needs to tell us about this discrepancy.

To answer your questions: gnustep-base is confugured with
--disable-bfd; gnustep-gui with --disable-icu-config
--enable-imagemagick. The compiler options used (in addition to those

Btw. I hope I fixed the disable-icu-config nusieance today :)

My first guess would be --enable-imagemagick

I remember fixing a couple of crashers, I don't remember they got into
release.
But I am testing on ImageMagick 6, maybe trixie only has 7, or has both
and 7 is being used.

I propose - at least for debugging purposes - to use a gui version
without ImageMagick and/or with ImageMagic 6.

No; we can't have PDFKit in Debian. The Debian gworkspace package
uses PopplerKit and it's the only patch to the pristine upstream
https://sources.debian.org/src/gworkspace/1.0.0-4/debian/patches/popplerkit.patch/

Ok, it still means you "enable" PDF support. However that is only used
with an Inspector and in the screenshot of Paul it was not enabled and
he is selecting an application and not an image or PDF doc.


Riccardo

[Paul Seelig]

Control: severity -1 grave
Control: tags -1 + moreinfo

[ snip ]

A screenshot is available at

http://wmlive.rumbero.org/NSInvalidArgumentException.png for a
visual depiction of the error message.

This shows NSContstantString(instance) but never mind.

Yes, my fault: The screenshot provided is from a bookworm system with
the backported GNUstep packages from trixie.

I have turned the image link into a directory and deposited in there two
different screenshots from both trixie and bookworm showing the
differing error message.

Could you please install gworkspace.app-dbgsym,
gworkspace-libs-dbgsym, libinspector0-dbgsym,
libgnustep-gui0.31-dbgsym, libgnustep-base1.30-dbgsym, libobjc4-dbgsym
$ gdb GWorkspace
(gdb) break -[NSException raise]
Function "-[NSException raise]" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (-[NSException raise]) pending
(gdb) r
...
(gdb) bt
And then post the backtrace you get? Thanks!

The backtrace has been produced according to your instructions and the
file gdb.log containing the out put has been attached to this mail.
A copy of the gdb.log has also been added as
http://wmlive.rumbero.org/NSInvalidArgumentException.png/gdb.log

I wanted to try making a clean i386 trixie install using official Debian
installation media but to my dismay there are no i386 daily build ISO
images available at https://www.debian.org/devel/debian-installer/
anymore. Looks like the i386 deprecation went a bit further than hoped for.

Thanks again,
Paul

[Yavor Doganov]

(gdb) bt
And then post the backtrace you get? Thanks!

Breakpoint 1, -[NSException raise] (self=0x3849d20,
_cmd=0xb77db730 <_OBJC_SELECTOR_TABLE+240>) at ./Source/NSException.m:1599
warning: 1599 ./Source/NSException.m: No such file or directory
[?2004h[?2004l

[?2004h(gdb) c

[?2004l

Continuing.

Thanks but this is not useful. When you hit the breakpoint, type
"bt" at the GDB prompt, not "c".

[Paul Seelig]

Post by Yavor Doganov
Continuing.
Thanks but this is not useful. When you hit the breakpoint, type
"bt" at the GDB prompt, not "c".

This time i set up a fresh system installation using a
debian-12.8.0-i386-netinst.iso which was subsequently dist-upgraded to
trixie.
This was to ensure a pristine Debian/Trixie installation before adding
Debian's official gnustep packages.

The error stays the same, unfortunately.

So here we go a second time with attachment GWorkspace_backtrace.log.

Also available at
Loading Image.../GWorkspace_backtrace.log

Thanks,
Paul

[Paul Seelig]

Hi Riccardo,

now let's hope the VCF Inspector can be fixed somehow.

it is very likely that you nailed it to this VCF Inspector!
now.. many things could be. The source code has a bug or bitrotted.
It was not rebuilt properly, ecc,
I suppose this is the VCFViewer from AddressManager itself, now?
Do you have this installed on your other systems too which you are
comparing with?

Yes, of course i tried every possible combination:

The GWorkspace error is not triggered on amd64 nor arm64, neither with
or without the addresses-goodies-for-gnustep package installed.

This only happens on i386 for me with the addresses-goodies-for-gnustep
package installed.

This doesn't look like it could be easily backtraced with gdb.

Any idea how i could help to debug?

Thanks,
Paul

[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

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.

[Paul Seelig]

Yavor,

you really did it!

Post by Yavor Doganov
$ 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.

This patch seems to have made the affected components behave and
GWorkspace doesn't crash anymore in whatever constellation i'm trying.

Thanks a lot to all of you for this funtastic support!

Best regards,
Paul

[Fred Kiefer]

Thank you Yavor for this patch. It looks correct to me and should resolve this specific issue. As for the code in the whole Address framework it will need a lot more of cleanup. Just skimming over it I noticed dozens of issues. i am quite surprised that this code does anything useful at all. If this library is in actual use, Riccardo and I should sit down together and try to clean it up. Otherwise it will come back and haunt us :-)
Great to see how you all worked together to understand and resolve this specific problem.

Cheers,
Fred

Post by 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

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
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
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.
$ 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.

[Yavor Doganov]

The screenshot provided is from a bookworm system with the
backported GNUstep packages from trixie.

Oh, I missed this. A "backport" means to rebuild the package for an
older distro release using the toolchain of the older release, and
older versions of the build-dependencies, if that is possible. If the
dependency information in your initial report is correct, that is not
the case -- glibc in bookworm is 2.36-9+deb12u9 and not 2.40-3, GCC is
12.2.0-14 and not 14.2.0-8. And of course the kernel in bookworm is
6.1.115 and not 6.10.12.

If the bug cannot be reproduced on bookworm (aka stable), trixie (aka
testing) or unstable (aka sid) with the stock Debian package, then I'm
afraid it's invalid (still, I'd like to know about it, what's causing
it and to get it fixed).

How did you make these backports, exactly? Is this a bookworm machine
dist-upgraded to trixie/sid? In that case you can just install the
stock Debian packages for everything; there's no need for backports.

[Paul Seelig]

Post by Yavor Doganov

The screenshot provided is from a bookworm system with the
backported GNUstep packages from trixie.

Oh, I missed this. A "backport" means to rebuild the package for an
older distro release using the toolchain of the older release, and
older versions of the build-dependencies, if that is possible. If the
dependency information in your initial report is correct, that is not
the case -- glibc in bookworm is 2.36-9+deb12u9 and not 2.40-3, GCC is
12.2.0-14 and not 14.2.0-8. And of course the kernel in bookworm is
6.1.115 and not 6.10.12.
If the bug cannot be reproduced on bookworm (aka stable), trixie (aka
testing) or unstable (aka sid) with the stock Debian package, then I'm
afraid it's invalid (still, I'd like to know about it, what's causing
it and to get it fixed).
How did you make these backports, exactly? Is this a bookworm machine
dist-upgraded to trixie/sid? In that case you can just install the
stock Debian packages for everything; there's no need for backports.

Just to clear up the confusion:

In fact i recompiled all those Trixie GNUstep source packages under
bookworm, making all necessary modifications to the build scripts to
ensure this compiles fine. While trying to run GWorkspace in Bookworm i
stumbled over the error shown in the first provided screenshot.

To verify if this is just a matter of my bookworm compilations i set up
a pure trixie environment using the Debian provided GNUstep packages.
And running GWorkspace in Trixie basically resulted in the similar issue
and thus trigered this bug report.

So this bug report is definitely about Trixie's official GWorkspace
application as provided by Debian and thus a valid issue.

Hope this helps to clear up any misunderstandings.

Thanks,
Paul

[Debian Bug Tracking System]

reassign -1 libaddressview0 0.4.8-5

Bug #1087735 [gworkspace.app] gworkspace.app: NSImage(instance) does not recognize subviews
Bug reassigned from package 'gworkspace.app' to 'libaddressview0'.
No longer marked as found in versions gworkspace/1.0.0-4.
Ignoring request to alter fixed versions of bug #1087735 to the same values previously set
Bug #1087735 [libaddressview0] gworkspace.app: NSImage(instance) does not recognize subviews
Marked as found in versions addresses-for-gnustep/0.4.8-5.

retitle -1 [i386] VCFViewer inspector aborts GWorkspace, making it unusable

Bug #1087735 [libaddressview0] gworkspace.app: NSImage(instance) does not recognize subviews
Changed Bug title to '[i386] VCFViewer inspector aborts GWorkspace, making it unusable' from 'gworkspace.app: NSImage(instance) does not recognize subviews'.

affects -1 gworkspace.app

Bug #1087735 [libaddressview0] [i386] VCFViewer inspector aborts GWorkspace, making it unusable
Added indication that 1087735 affects gworkspace.app

tags -1 + patch

Bug #1087735 [libaddressview0] [i386] VCFViewer inspector aborts GWorkspace, making it unusable
Added tag(s) patch.

[Debian Bug Tracking System]

Your message dated Wed, 20 Nov 2024 10:49:10 +0000
with message-id <E1tDiGk-00A8dB-***@fasolo.debian.org>
and subject line Bug#1087735: fixed in addresses-for-gnustep 0.4.8-6
has caused the Debian Bug report #1087735,
regarding [i386] VCFViewer inspector aborts GWorkspace, making it unusable
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ***@bugs.debian.org
immediately.)