> Am 03.08.2018 um 00:38 schrieb Riccardo Mottola <riccardo.mott...@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. _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep