|
| From: | Andreas Höschler |
| Subject: | Re: GNUstep app fails on Ubuntu 16 - found workaround |
| Date: | Fri, 8 May 2020 16:31:24 +0200 |
Hi Riccardo and all,
In the meanwhile I have inserted an [NSException raise:...] into /libs-back/Source/x11/XWindowBuffer.m if (!wi->ximage) { NSLog(@"Warning: XShmCreateImage failed!"); NSLog(@"Falling back to normal XImage (will be slower)."); goto no_xshm; } wi->shminfo.shmid = shmget(IPC_PRIVATE, wi->ximage->bytes_per_line * wi->ximage->height, IPC_CREAT | 0700); if (wi->shminfo.shmid == -1) { NSLog(@"Warning: shmget() failed: %m."); NSLog(@"Falling back to normal XImage (will be slower)."); [NSException raise:NSInternalInconsistencyException format:@"asas"]; // <-- remove this XDestroyImage(wi->ximage); goto no_xshm; } to get a backtrace of what triggers the shmget() problem and got this #0 -[NSException raise] (self=0x46c75c0, _cmd=0x7ffff6ac64e0 <_OBJC_SELECTOR_TABLE+480>) at NSException.m:1574 #1 0x00007ffff6565bba in +[NSException raise:format:arguments:] (self=0x7ffff6ac6020 <_OBJC_Class_NSException>, _cmd=0x7ffff6ac64b0 <_OBJC_SELECTOR_TABLE+432>, name=0x7ffff6ac59e0 <_OBJC_INSTANCE_4>, format=0x7fffee2ccd50 <_OBJC_INSTANCE_12>, argList=0x7fffffffca10) at NSException.m:1465 #2 0x00007ffff6565b01 in +[NSException raise:format:] (self=0x7ffff6ac6020 <_OBJC_Class_NSException>, _cmd=0x7fffee2cd3b0 <_OBJC_SELECTOR_TABLE+176>, name=0x7ffff6ac59e0 <_OBJC_INSTANCE_4>, format=0x7fffee2ccd50 <_OBJC_INSTANCE_12>) at NSException.m:1450 #3 0x00007fffee05d046 in +[XWindowBuffer windowBufferForWindow:depthInfo:] (self=0x7fffee2cd280 <_OBJC_Class_XWindowBuffer>, _cmd=0x7fffee2d2320 <_OBJC_SELECTOR_TABLE+320>, awindow=0x1072ce0, aDI=0x7fffffffcba0) at XWindowBuffer.m:322 #4 0x00007fffee0620d7 in -[ARTGState(internal) stuff:GSSetDevice:::] (self=0x1087990, _cmd=0x7fffee2d1840 <_OBJC_SELECTOR_TABLE+352>, window=0x1072ce0, x=1, y=10000547) at ARTGState.m:644 #5 0x00007fffee05e933 in -[ARTContext(ops) GSSetDevice:::] (self=0x3f7f2f0, _cmd=0x7fffee2ca860 <_OBJC_SELECTOR_TABLE+1472>, device=0x1072ce0, x=1, y=10000547) at ARTContext.m:164 #6 0x00007fffee04a30f in GSSetDevice (ctxt=0x3f7f2f0, device=0x1072ce0, x=1, y=10000547) at /usr/GNUstep/Local/Library/Headers/AppKit/DPSOperators.h:1153 #7 0x00007fffee052111 in -[XGServer(WindowOps) setWindowdevice:forContext:] (self=0xa53760, _cmd=0x7fffee2ba080 <_OBJC_SELECTOR_TABLE+448>, win=164, ctxt=0x3f7f2f0) at XGServerWindow.m:2683 #8 0x00007fffee022ed5 in -[GSContext initWithContextInfo:] (self=0x3f7f2f0, _cmd=0x7ffff7d676e0 <_OBJC_SELECTOR_TABLE+3520>, info=0x46cad70) at GSContext.m:226 #9 0x00007ffff78b598d in -[NSWindow _startBackendWindow] (self=0x108b160, _cmd=0x7ffff7d67770 <_OBJC_SELECTOR_TABLE+3664>) at NSWindow.m:915 #10 0x00007ffff78b5d69 in -[NSWindow _initBackendWindow] (self=0x108b160, _cmd=0x7ffff7d67890 <_OBJC_SELECTOR_TABLE+3952>) at NSWindow.m:967 #11 0x00007ffff78b66f7 in -[NSWindow initWithContentRect:styleMask:backing:defer:] (self=0x108b160, _cmd=0x7ffff3970980 <_OBJC_SELECTOR_TABLE+1888>, contentRect=..., aStyle=15, bufferingType=2, flag=0 '\000') at NSWindow.m:1100 #12 0x00007ffff370ed00 in -[GSMarkupTagWindow platformObjectInit] (self=0x21f6c20, _cmd=0x7ffff3952c80 <_OBJC_SELECTOR_TABLE+2272>) at GSMarkupTagWindow.m:180 The corresponding code is GSMarkupTagWindow: ========================== - (void)platformObjectInit { ... NSLog(@"contentRect %@ style %d backingType %d", NSStringFromRect(contentRect), style, backingType); [self setPlatformObject:[_platformObject initWithContentRect:contentRect styleMask:style backing:backingType defer:NO]]; .... } and the output of the log line is 2020-05-08 13:42:59.862 SOSmartBrowser[29363:29363] _rootTagObject <GSMarkupTagVBox: 0x86e5290> contentView h=-&- v=-&- <GSVBox: 0xdce1550> f={x = 0; y = 0; width = 0; height = 0} b={x = 0; y = 0; width = 0; height = 0} 2020-05-08 11:43:19.108 SOObjectBrowser[28857:28857] contentRect {x = 20; y = 20; width = 1022; height = 1.00005e+07} style 15 backingType 2 Aha!! height = 1.00005e+07 looks a bit to large. Cocoa and the old GNUstep tree got a long with this request. The more recent code seems to be a bit pickier. :-) I dived a little deeper into the code and found that the following NSView category method produces the unreasonable values. - (NSSize)minimumSizeForContent { NSRect oldFrame; NSSize minimumSize; /* Save the oldFrame. */ oldFrame = [self frame]; /* Resize the view to fit the contents ... this is the only * way available in the AppKit to get the minimum size. */ [self sizeToFitContent]; /* Get the minimum size by reading the frame. */ minimumSize = [self frame].size; /* Restore the original frame. */ [self setFrame:oldFrame]; return minimumSize; } more explicitly @implementation NSControl (sizeToContent) - (void)sizeToFitContent { [self sizeToFit]; } @end does and even more explicitly NSButton:: sizeToFit pico ./Source/NSControl.m /**<p>Resizes the NSControl to fits the NSControl's cell size.</p> <p>See Also: [NSCell-cellSize]</p> */ - (void) sizeToFit { [self setFrameSize: [_cell cellSize]]; } It turns out that the problem occurs on all forms that have NSButtons that have been customised with image = [[[NSImage alloc] initWithContentsOfFile:path] autorelease]; if (image) { [someButton setImage:image]; } My first measure (ugly hack) was to do @implementation NSControl (sizeToContent) - (void)sizeToFitContent { [self sizeToFit]; NSSize size = [self frame].size; if (size.height > 10000.0) { NSLog(@"Got height %f. We correct this ...", size.height); [self setFrameSize: NSMakeSize(size.width, 24.0)]; // <-- just some phantaise value } } @end This fixes the problem for me. The forms open and the app works nicely. The academic question remains what makes NSControl::sizeToFit to fail so badly for buttons with images? Since others have hit this as well (see one of my mails from yesterday) this should probably be addressed in the GNUstep code. Does this ring any bells? Thanks a lot, Andreas |
| [Prev in Thread] | Current Thread | [Next in Thread] |