Re: Crash on app start due to icon

[Fred Kiefer]

> Am 03.08.2018 um 00:38 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
> Fred Kiefer wrote:
>> This is really weird. Could it be that a theme is causing this? If not I 
>> would as always suggest to run the program under valgrind to see what is the 
>> real cause of the issue. You could also try to output the variable „anImage“ 
>> instead of „_app_icon“ and try to inspect that with the command „p *anImage“.
>> 
>> We could try to make the image loading lazy, which would move it back a bit 
>> again. But first we should try to understand what is going on on your 
>> machines and why this is only happening there.
> I wonder that only I do see this... It actually happens on most my 
> machines... the only one(s) where not are the FeeBSD+Clang ones (can't get 
> GCC work on FreeBSD yet due to libobjc2 issues, so I cannot verify that 
> factor)

Does this mean you only tested on clang systems? It could be a clang bug, which 
version of clang are you using?

> Program received signal SIGSEGV, Segmentation fault.
> 0xb7b3b1a6 in -[NSApplication setApplicationIconImage:] (
>     self=0xb7b384f7 <-[NSApplication(Private) _loadAppIconImage]+503>,
>     _cmd=0x81ba670, anImage=0xb7ed3238 <_OBJC_SELECTOR_TABLE+3256>)
>     at NSApplication.m:2392
> 2392      imageSize = [_app_icon size];
> (gdb) p _app_icon
> $1 = (struct NSImage *) 0x548b0cc4
> (gdb) p anImage
> $2 = (struct NSImage *) 0xb7ed3238 <_OBJC_SELECTOR_TABLE+3256>
> (gdb) po anImage
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb74d3f36 in objc_msg_lookup () from /usr/lib/i386-linux-gnu/libobjc.so.4
> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on".
> Evaluation of the expression containing the function
> (_NSPrintForDebugger) will be abandoned.
> When the function is done executing, GDB will silently stop.
> 
> so.... I restarted and retried:
> 
> (gdb) p anImage
> $3 = (struct NSImage *) 0xb7ed3238 <_OBJC_SELECTOR_TABLE+3256>
> (gdb) p *anImage
> $4 = {{isa = 0x140076}, _name = 0xb7ecfa84 <_OBJC_METH_VAR_TYPE_0>,
>   _fileName = 0x150076, _size = {width = -2.82472465e-05,
>     height = 2.02054627e-39}, _flags = {archiveByName = 0, scalable = 0,
>     dataRetained = 0, flipDraw = 0, sizeWasExplicitlySet = 0,
>     useEPSOnResolutionMismatch = 1, colorMatchPreferred = 0,
>     multipleResolutionMatching = 0, cacheSeparately = 0,
>     unboundedCacheDepth = 0, syncLoad = 1}, _reps = 0x5006e,
>   _color = 0xb7ecf3e0 <_OBJC_METH_VAR_TYPE_437>, _lockedView = 0x170076,
>   _delegate = 0xb7ecfa84 <_OBJC_METH_VAR_TYPE_0>, _cacheMode = 1769539}
> 
> 
> it has a ridiculous size I'd say?

No, this is just zero, which is the normal initial state for size. What is 
strange is that _lockedView is set. This should not be the case. Also the value 
looks very similar to the isa and the _fileName pointer. Could it be that clang 
or the library it uses does not clean up the memory for a new object? Or this 
is an artefact of the debugger.

As usual I would suggest to run the program under valgrind :-)

To work around this issue with the application icon, I could add a bit of code 
to gui that does lazy evaluation of this icon. But most likely you will still 
get an error, just a bit later.