Crash on app start due to icon

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Gregory Casamento
Hello,

On Sun, Aug 5, 2018 at 05:27 Wolfgang Lux <[hidden email]> wrote:
Hi Riccardo,

I finally managed to reproduce the crash, once I've noticed that you are compiling on a 32-bit OS rather than 64-bits (any reason for not using 64-bits nowadays?). Setting a breakpoint on the setApplicationIconImage: and then stepping through that method I found that the code crashes here:
2385      miniWindowSize = [GSCurrentServer() iconSize];

And stepping into that method the problem is that GSCurrentServer() return a null pointer. I've committed a fix now to handle this case.

Wolfgang

Why on earth is GSCurrentServer() returning null?  



> Am 04.08.2018 um 23:10 schrieb Riccardo Mottola <[hidden email]>:
>
> Hi,
>
>
> On 08/04/18 13:53, Wolfgang Lux wrote:
>> as everybody else I'm also unable to reproduce your issue on NetBSD 7.1.2 with the latest source (except for Fred's patch). So it's seems this is something peculiar with your setup. Do you have any themes installed? If so, can you install them and try again. Also, what is the output of
>>   info sharedlibrary
>> (you may abbreviate that to i sh) when the program crashes?
>
> this is a mystery: I get a crash on all my computers except the FreeBSD/clang ones (both laptop and workstation).
>
> On my NetBSD 8.0 I had themes installed, namely set was the tango theme:
> imladris: {21} defaults read NSGlobalDomain GSTheme
> NSGlobalDomain GSTheme Tango
>
> this is a pure icon theme.
>
> I removed all the themes and removed the GSTheme variable, to "clean" everything, but I still get a crash.
>
> I have these configuration settings.
>
> Make:
>   $ ./configure --prefix=/ --with-layout=gnustep
>
> Base, Gui and Back: just configure with no arguments. Cairo is installed, detected and used.
>
> It is window-maker dependent (only there we have the icon dock). If I quickly switch to plain twm, the application starts.
>
> Riccardo
>


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Fred Kiefer


> Am 05.08.2018 um 22:26 schrieb Gregory Casamento <[hidden email]>:
>
> On Sun, Aug 5, 2018 at 05:27 Wolfgang Lux <[hidden email]> wrote:
>
> I finally managed to reproduce the crash, once I've noticed that you are compiling on a 32-bit OS rather than 64-bits (any reason for not using 64-bits nowadays?). Setting a breakpoint on the setApplicationIconImage: and then stepping through that method I found that the code crashes here:
> 2385      miniWindowSize = [GSCurrentServer() iconSize];
>
> And stepping into that method the problem is that GSCurrentServer() return a null pointer. I've committed a fix now to handle this case.
>
> Why on earth is GSCurrentServer() returning null?  

Because somebody (hint: you) did change the order in which this methods get called. If you have a look at the NSApplication _init method you will see that the backend gets initialised first and then the current display server is set. This order is needed as the display server is defined by the backend. Now you did move the loading of the application icon before that and there we use the setApplicationIcon: method which refers to the GSCurrentServer().

My attempt to lazy load the icon only when it is needed didn’t help here, as actually this gets called from the backend when it is being initialised, which is still before the current display server is set.

The important bit here are these lines:

srv = [GSDisplayServer serverWithAttributes: nil];
RETAIN(srv);
[GSDisplayServer setCurrentServer: srv];

Only after the third one the current server is set, but the code triggered from the first line will call the applicationIcon method for the WindowMaker dock.

Wolfgangs fix is actually quite a good workaround for this.

Fred


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Gregory Casamento
Fred,

On Sun, Aug 5, 2018 at 16:47 Fred Kiefer <[hidden email]> wrote:


> Am 05.08.2018 um 22:26 schrieb Gregory Casamento <[hidden email]>:
>
> On Sun, Aug 5, 2018 at 05:27 Wolfgang Lux <[hidden email]> wrote:
>
> I finally managed to reproduce the crash, once I've noticed that you are compiling on a 32-bit OS rather than 64-bits (any reason for not using 64-bits nowadays?). Setting a breakpoint on the setApplicationIconImage: and then stepping through that method I found that the code crashes here:
> 2385      miniWindowSize = [GSCurrentServer() iconSize];
>
> And stepping into that method the problem is that GSCurrentServer() return a null pointer. I've committed a fix now to handle this case.
>
> Why on earth is GSCurrentServer() returning null? 

Because somebody (hint: you) did change the order in which this methods get called. If you have a look at the NSApplication _init method you will see that the backend gets initialised first and then the current display server is set. This order is needed as the display server is defined by the backend. Now you did move the loading of the application icon before that and there we use the setApplicationIcon: method which refers to the GSCurrentServer().

Oh damn.  I actually thought I was preserving the order when I made the change.  The issue I was seeing with getting the icon was caused by the fact that we needed to initialize the backend first before getting the icon.  This is why I split it out into two methods. 

My attempt to lazy load the icon only when it is needed didn’t help here, as actually this gets called from the backend when it is being initialised, which is still before the current display server is set.

The important bit here are these lines:

srv = [GSDisplayServer serverWithAttributes: nil];
RETAIN(srv);
[GSDisplayServer setCurrentServer: srv];

Only after the third one the current server is set, but the code triggered from the first line will call the applicationIcon method for the WindowMaker dock.

Okay. 



Wolfgangs fix is actually quite a good workaround for this.

I’m surprised neither of us picked this up on review.

Thanks Fred, Riccardo and Wolfgang. 


Fred

Yours, GC
--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Riccardo Mottola-5
In reply to this post by Wolfgang Lux
Wolfgang Lux wrote:
> I finally managed to reproduce the crash, once I've noticed that you are compiling on a 32-bit OS rather than 64-bits (any reason for not using 64-bits nowadays?). Setting a breakpoint on the setApplicationIconImage: and then stepping through that method I found that the code crashes here:
> 2385      miniWindowSize = [GSCurrentServer() iconSize];
>
> And stepping into that method the problem is that GSCurrentServer() return a null pointer. I've committed a fix now to handle this case.

It fixes it, I quickly tested on one laptop (NetBSD 8), will test on the
rest as soon as possible!

I use 32bit when the hardware below is 32bit :) The ThinkPads I worked
on these weeks were all 32bit indeed, except by change the two 64bit
systems I used... were runninf FreeBSD! Unlucky coincidence to diagnose.

Actually SPARC was 64bit, but it has always issues.

I will try my best to test on more systems, including OpenBSD 32bit and
64bit before holidays and report back!

I wonder however now if the patch is corect, since Gregory changed
initialization order. I also wonder more about the behaviour we are having:

- app starts I see a grey icon bouncing in the WM dock
. once completed, the icon appears

I think we should tell the windowmanager (perhaps needed only for
WindowMaker) the tiff file, so that it displays the "icon" immediatly
while launching without the need of having a bacckend, later then the
app icon can be shown/subsitituted For most application this doesn't
make a difference.

E.g. with batmon, I would expect this:
- during start, seeing the static application icon (which is teh same
that neesd
- once started, see the battery level

instead it remains grey and then just shows the battery level.

Last question then: I think all this fix was about telling WindowMaker
the icon, so that it could be "docket" succesfully and the Icon remain
in the dock once closed, something which used to work, but it doesn't
and Greg's patch does not fix that. So what does it fix?


Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Wolfgang Lux
Hi Riccardo,

>
> Wolfgang Lux wrote:
>> I finally managed to reproduce the crash, once I've noticed that you are compiling on a 32-bit OS rather than 64-bits (any reason for not using 64-bits nowadays?). Setting a breakpoint on the setApplicationIconImage: and then stepping through that method I found that the code crashes here:
>> 2385      miniWindowSize = [GSCurrentServer() iconSize];
>>
>> And stepping into that method the problem is that GSCurrentServer() return a null pointer. I've committed a fix now to handle this case.
>
> It fixes it, I quickly tested on one laptop (NetBSD 8), will test on the rest as soon as possible!
>
> I use 32bit when the hardware below is 32bit :) The ThinkPads I worked on these weeks were all 32bit indeed, except by change the two 64bit systems I used... were runninf FreeBSD! Unlucky coincidence to diagnose.

Ah, okay. I keep forgetting that you like using some ancient hardware (no offense intended: I still have a 15+ years old PowerBook sitting on my desktop and it's nice being able to power it up with no hassles when I need it, although that's not very often nowadays). :-)

>
> Actually SPARC was 64bit, but it has always issues.

Yes, I was even about to mention that you should be seeing that issue on Sparc, too. :-)

>
> I will try my best to test on more systems, including OpenBSD 32bit and 64bit before holidays and report back!
>
> I wonder however now if the patch is corect, since Gregory changed initialization order. I also wonder more about the behaviour we are having:
>
> - app starts I see a grey icon bouncing in the WM dock
> . once completed, the icon appears

Is that a regression before Greg made his change or did you observe that issue before as well?

Wolfgang


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Riccardo Mottola-5
Hi,


On 08/06/18 15:19, Wolfgang Lux wrote:
>
> Ah, okay. I keep forgetting that you like using some ancient hardware (no offense intended: I still have a 15+ years old PowerBook sitting on my desktop and it's nice being able to power it up with no hassles when I need it, although that's not very often nowadays). :-)

Well.. I have a mix of various machines.. and the vintage ThinkPads are
still quite capable and have nicer keybards and handling than newer ones!
>> I will try my best to test on more systems, including OpenBSD 32bit and 64bit before holidays and report back!

I just tested Ubuntu on Linux/x86 on the other ThinkPad 43 I have and it
is fixed.
I also tested on OpenBSD/amd64 and it (continues) to work.

Of course it retains the "behaviour" of the grey Icon until launch
completes.
Interestingly, on Ubuntu I can actually dock an app and it will retain
the icon, on OpenBSD instead it WindowMaker will revert to generic.

>>
>> I wonder however now if the patch is corect, since Gregory changed initialization order. I also wonder more about the behaviour we are having:
>>
>> - app starts I see a grey icon bouncing in the WM dock
>> . once completed, the icon appears
> Is that a regression before Greg made his change or did you observe that issue before as well?

If I am not mistaken, it is not a regression, it is just something I
noticed (again) while looking at this.
Does it happen for you? Some apps start quick so you don't notice, but
on a slower/loaded machine it is clear.

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Josh Freeman
In reply to this post by Wolfgang Lux
On Aug 5, 2018, at 5:22 AM, Wolfgang Lux wrote:

> I finally managed to reproduce the crash, once I've noticed that you  
> are compiling on a 32-bit OS rather than 64-bits (any reason for not  
> using 64-bits nowadays?).

    Good catch, now I'm seeing the crash as well (Ubuntu 16.04.5, 32-
bit).


> Setting a breakpoint on the setApplicationIconImage: and then  
> stepping through that method I found that the code crashes here:
> 2385      miniWindowSize = [GSCurrentServer() iconSize];

    It seems to be a gcc/gobjc compiler/runtime bug: Sending a nil  
message using a method signature that returns a structure (ex. -
[NSView bounds] -> NSRect) results in:
1. Garbage values in the returned structure's members (affects: 32-bit/
64-bit, debug/non-debug)
2. A corrupted stack (affects: 32-bit w/non-debug)

    Attached are two files:
- nil_msg_check.m: source for a simple test program, NilMsgCheck,  
which sends a nil message that returns an NSSize value
- GNUmakefile: makefile for NilMsgCheck

-----
Output from running NilMsgCheck on gcc/gobjc 32-bit non-debug:

[self nmcZeroSize] returned: {width = 0; height = 0}
[nil nmcZeroSize] returned: {width = -2.90002e-05; height = 0}
*** stack smashing detected ***: ./obj/NilMsgCheck terminated
Aborted (core dumped)

    (If the nil-message is commented-out (nil_msg_check.m:22),  
NilMsgCheck exits normally without error)

----
Output from running NilMsgCheck on gcc/gobjc 32-bit debug:

[self nmcZeroSize] returned: {width = 0; height = 0}
[nil nmcZeroSize] returned: {width = -2.74035e-05; height =  
-2.78249e-05}

    (Exits normally)

----
Output from running NilMsgCheck on clang/objc2 32-bit debug:

[self nmcZeroSize] returned: {width = 0; height = 0}
[nil nmcZeroSize] returned: {width = 0; height = 0}

    (Exits normally, values are correctly zeroed)



Cheers,

Josh






_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

nil_msg_check.m (730 bytes) Download Attachment
GNUmakefile (149 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Fred Kiefer
Great test code! Could you please file this as a bug report for gcc? I am a bit unsure whether the issue is in gcc itself or in libobjc but both are handled in the same bug tracking system.

Fred

> Am 08.08.2018 um 00:34 schrieb Josh Freeman <[hidden email]>:
>
> On Aug 5, 2018, at 5:22 AM, Wolfgang Lux wrote:
>
>> I finally managed to reproduce the crash, once I've noticed that you are compiling on a 32-bit OS rather than 64-bits (any reason for not using 64-bits nowadays?).
>
>   Good catch, now I'm seeing the crash as well (Ubuntu 16.04.5, 32-bit).
>
>
>> Setting a breakpoint on the setApplicationIconImage: and then stepping through that method I found that the code crashes here:
>> 2385      miniWindowSize = [GSCurrentServer() iconSize];
>
>   It seems to be a gcc/gobjc compiler/runtime bug: Sending a nil message using a method signature that returns a structure (ex. -[NSView bounds] -> NSRect) results in:
> 1. Garbage values in the returned structure's members (affects: 32-bit/64-bit, debug/non-debug)
> 2. A corrupted stack (affects: 32-bit w/non-debug)
>
>   Attached are two files:
> - nil_msg_check.m: source for a simple test program, NilMsgCheck, which sends a nil message that returns an NSSize value
> - GNUmakefile: makefile for NilMsgCheck
>
> -----
> Output from running NilMsgCheck on gcc/gobjc 32-bit non-debug:
>
> [self nmcZeroSize] returned: {width = 0; height = 0}
> [nil nmcZeroSize] returned: {width = -2.90002e-05; height = 0}
> *** stack smashing detected ***: ./obj/NilMsgCheck terminated
> Aborted (core dumped)
>
>   (If the nil-message is commented-out (nil_msg_check.m:22), NilMsgCheck exits normally without error)
>
> ----
> Output from running NilMsgCheck on gcc/gobjc 32-bit debug:
>
> [self nmcZeroSize] returned: {width = 0; height = 0}
> [nil nmcZeroSize] returned: {width = -2.74035e-05; height = -2.78249e-05}
>
>   (Exits normally)
>
> ----
> Output from running NilMsgCheck on clang/objc2 32-bit debug:
>
> [self nmcZeroSize] returned: {width = 0; height = 0}
> [nil nmcZeroSize] returned: {width = 0; height = 0}
>
>   (Exits normally, values are correctly zeroed)
>
>
>
> Cheers,
>
> Josh
>
>
> <nil_msg_check.m><GNUmakefile>
>
> _______________________________________________
> Discuss-gnustep mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Riccardo Mottola-5
Hi Fred,

Fred Kiefer wrote:
> Great test code! Could you please file this as a bug report for gcc? I am a bit unsure whether the issue is in gcc itself or in libobjc but both are handled in the same bug tracking system.

if libobjc2 worked for GCC I could have tested that combination :) I was
working on that with David when he asked me for certain tests I did not
know how to write. Maybe now that you are back we can do that together.

Actually I remember that on SPARC you traditinally cannot access a
structure of a nil object, but that is different from calling a method
of a nil object, right?
That should have worked everywhere?

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Wolfgang Lux
In reply to this post by Riccardo Mottola-5
Hi Riccardo,

> Of course it retains the "behaviour" of the grey Icon until launch completes.
> Interestingly, on Ubuntu I can actually dock an app and it will retain the icon, on OpenBSD instead it WindowMaker will revert to generic.

on NetBSD 8 with WindowMaker 0.95.8 the icon isn't retained either.

>
>>>
>>> I wonder however now if the patch is corect, since Gregory changed initialization order. I also wonder more about the behaviour we are having:
>>>
>>> - app starts I see a grey icon bouncing in the WM dock
>>> . once completed, the icon appears
>> Is that a regression before Greg made his change or did you observe that issue before as well?
>
> If I am not mistaken, it is not a regression, it is just something I noticed (again) while looking at this.
> Does it happen for you? Some apps start quick so you don't notice, but on a slower/loaded machine it is clear.

It's hard to notice for me. From the few applications I've tested, perhaps it was most obvious for batmon.app.
I think the problem is the hack I committed a few years back to fix the issue with the first application opened in WindowMaker not getting a proper application menu. The problem is that the app icon must be the first window that is created and mapped by the application for us to be able to set the application menu. To make that work, my fix creates the app icon window early on in -[XGServer _setupRootWindow]. In particular, it does that before the method tries to determine the size of the window borders by creating a set of (off-screen) windows. But since we don't know the app icon at the time when _setupRootWindow is called, this means that the app icon will remain blank (well, grey) until the icon gets set later. :-(

Wolfgang



_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Riccardo Mottola-5
Hi Wolfgang,

Wolfgang Lux wrote:
> Hi Riccardo,
>
>> Of course it retains the "behaviour" of the grey Icon until launch completes.
>> Interestingly, on Ubuntu I can actually dock an app and it will retain the icon, on OpenBSD instead it WindowMaker will revert to generic.
> on NetBSD 8 with WindowMaker 0.95.8 the icon isn't retained either.

I did further test, also on a second OpenBSD machine, ir confirms that
it does not work. On FreeBSD however it works...

I noticed the following: check the docked icon properties, you should
see the .xpm file
I have seen different behaviours:
1) before any fix, this was empty IIRC
2) just the file name
3) relative path to user root
4) absolute path

the file is form me inside WindowMaker defaults library.

on OpenBSD it is not a full path. However, if I search the path, it
exists in the expected place. If I susbsitute the path then the icon
appears!


> It's hard to notice for me. From the few applications I've tested, perhaps it was most obvious for batmon.app.

GWorkspace may be slow to start sometimes, but yes, batmon or TimeMon
are the examples where the icon and running icon aver very different.

> I think the problem is the hack I committed a few years back to fix the issue with the first application opened in WindowMaker not getting a proper application menu. The problem is that the app icon must be the first window that is created and mapped by the application for us to be able to set the application menu. To make that work, my fix creates the app icon window early on in -[XGServer _setupRootWindow]. In particular, it does that before the method tries to determine the size of the window borders by creating a set of (off-screen) windows. But since we don't know the app icon at the time when _setupRootWindow is called, this means that the app icon will remain blank (well, grey) until the icon gets set later. :-(

Some chicken-and-egg issue with the backend?

Can we display the TIFF/icns icon as a first thing perhaps? Actually the
one we are passing as atom! I think the window manager could display it
before.

The whole off-screen windows is another issue :) But we may go
off-topic. But suppose the following scenario: you have a login
applicatino like xdm: it runs before the user's window manager is
started, it runs on bare X11.. try to do that on GNUstep, it complains,
is slow and sets up offset wrong :)

Riccardo

_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Reply | Threaded
Open this post in threaded view
|

Re: Crash on app start due to icon

Yavor Doganov-3
In reply to this post by Josh Freeman
On Wed, 08 Aug 2018 01:34:25 +0300,
Josh Freeman wrote:
>    It seems to be a gcc/gobjc compiler/runtime bug: Sending a nil
> message using a method signature that returns a structure
> (ex. -[NSView bounds] -> NSRect) results in:
> 1. Garbage values in the returned structure's members (affects:
> 32-bit/64-bit, debug/non-debug)
> 2. A corrupted stack (affects: 32-bit w/non-debug)

Many thanks for finding this out.  It explains many hours spent in
fruitless debugging sessions and some truly obscure bugs I've seen in
Adun, Cenon, Lynkeos and other apps...  Unfortunately this bug has
nasty consequences as quite a lot of GUI methods return structs and
most users (and distros) usually build with -O2.

The good news is that I managed to find out the revisions which fixed
the bug and reintroduced it again, reworked your test program to pure
Objective-C and reported it:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86913


_______________________________________________
Discuss-gnustep mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
12