[bug #23333] -initWithFocusedViewRect: seems to crash with clipped views

[Quentin Mathé]

URL:
  <http://savannah.gnu.org/bugs/?23333>

                 Summary: -initWithFocusedViewRect: seems to crash with
clipped views
                 Project: GNUstep
            Submitted by: qmathe
            Submitted on: vendredi 23.05.2008 à 17:09
                Category: Gui/AppKit
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Ubuntu 7.10
gnustep-base r26119
gnustep-gui r26262
gnustep-back (art) r26014

I use the following method in an NSImage category to take snapshots of
views.

// I take care to only pass the visible rect of view as sourceRect
- (void) takeSnapshotFromRect: (NSRect)sourceRect inView: (NSView *)view
{
        NSBitmapImageRep *rep = nil;
        
        if ([view window] == nil || [view canDraw] == NO)
        {
                ETLog(@"WARNING: Impossible to snapshot view %@", view);
                return;
        }

        [view lockFocus];
        rep = [[NSBitmapImageRep alloc] initWithFocusedViewRect: sourceRect];
        [view unlockFocus];

        [self addRepresentation: rep];
        RELEASE(rep);
}

It works very well on Cocoa, but I have troubles with it on GNUstep. I often
got the following segfaults, here is the end of the stack trace:

#0  0xb70d6d8a in bgra_read_pixels_o (c=0xbf8f1aec, num=134) at blit.m:436
#1  0xb70fe546 in -[ARTGState(ReadRect) GSReadRect:] (self=0x8511f48,
_cmd=0xb71089f0, r=
      {origin = {x = 0, y = 0}, size = {width = 580, height = 261}}) at
ReadRect.m:132
#2  0xb7097d6c in -[GSContext(NSGraphics) GSReadRect:] (self=0x83deb08,
_cmd=0xb7dcc6f8, 
      rect={origin = {x = 0, y = 0}, size = {width = 580, height = 261}})
      at GSContext.m:872
#3  0xb7b9b7bb in -[NSBitmapImageRep initWithFocusedViewRect:]
(self=0x8451350, 
     _cmd=0xb7f22ed8, rect={origin = {x = 0, y = 0}, size = {width = 580,
height = 261}})
     at NSBitmapImageRep.m:323
#4  0xb7eec06f in -[NSImage(Etoile) takeSnapshotFromRect:inView:]
(self=0x8316160, 
     _cmd=0xb7f22ea0, sourceRect=
     {origin = {x = 0, y = 0}, size = {width = 580, height = 261}},
view=0x83e0598)
     at NSImage+Etoile.m:93

I have been able to reproduce it in a relatively simple case which consists
of calling this method with an image view, located inside a scroll view, and
partially or fully obscured by the clip view. If the image view is fully
visible within the scroll view (scrollers disabled), the snapshot doesn't
trigger a segfault. On the other hand, if I resize the scroll view to clip the
content and get the scrollers enabled then I get a segfault if I try to take a
snapshot on this image view. Taking a snapshot on the scroll view seems to be
fine though. 

I have other cases where I get this crash by taking a snapshot of a
table/outline or browser views, but they are more complicated to reproduce.
May be that's only one bug since table/outline and browser views are all
enclosed inside a scroll view by default (when you use the Gorm provided
instances)... Not really sure about that though.

By reading the stack trace, it looks like GNUstep is unable to provide valid
data for a view that is clipped even if the view belongs to a window and
doesn't report a problem when -lockFocus is called on it. It would be great to
have the same behavior than Cocoa but if it's too complicated, I'd like to
suggest the method should return a nil image rep in such problematic cases
instead of crashing. May be -lockFocus should log a message too...
The Cocoa implementation isn't perfect because it doesn't check for [view
window] == nil, it just crashes in a very weird way. -canDraw doesn't help in
my test. May be GNUstep could implement this extra check [view window] == nil.


Thanks,
Quentin.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?23333>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/