[bug #20453] netbsd gui thread safety

[Paul D. Smith]

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

                 Summary: netbsd gui thread safety
                 Project: GNUstep
            Submitted by: rmottola
            Submitted on: Wednesday 07/11/2007 at 21:24
                Category: Gui/AppKit
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

recent changes to the alert Panel made it work reliably on Linux when called
form outside the main thread.
I discovered that it isn't so reliable on netBSD! The same test application
applies: FTP from GAP in its current CVS version. Trigger an alert pane by
for example trying to upload a file in a place where you don't have
permissions.
on Mac you reliably get an Alert Panel. On Linux/GNUstep you get a warning
but it works. It is indended.
On NetBSD sometimes it works,. sometimes not: nothing pops up  and I don't
get the NSLOg warning either! I keep just hitting the upload button to
triggger the event.. very strange.

In the same way when I download/upload a file the working task does some
updates (writes a string and moves theprogress bar). On linux this currently
works fine. on NetBSD it may crash:

/home/multix/gnustep-rep/gap/user-apps/FTP/FTP.app/FTP: Uncaught exception
NSInvalidArgumentException, reason: Tried to add nil to array







    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Update of bug #20453 (project gnustep):

              Item Group:                    None => Bug                    

    _______________________________________________________

Follow-up Comment #1:

Could you please run the application with the --debug option and report back
the full back traces?

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Follow-up Comment #2, bug #20453 (project gnustep):

this is stack trace just on download, I don't think an alert panel should
have popped up, thus it is a problem with the update from a thread, I
suppose. On Mac or Linux I never got that. Xlib backend.


#0  0xbd3fc023 in poll () from /usr/lib/libc.so.12
#1  0xbd4deded in poll () from /usr/lib/libpthread.so.0
#2  0xbd0ad8d4 in _XPollfdCacheDel () from /usr/X11R6/lib/libX11.so.6
#3  0xbd0ae605 in _XRead () from /usr/X11R6/lib/libX11.so.6
#4  0xbd0af047 in _XReply () from /usr/X11R6/lib/libX11.so.6
#5  0xbd068e48 in XGetImage () from /usr/X11R6/lib/libX11.so.6
#6  0xbd1a25e6 in RGetXImage (context=0x81d2980, d=14680339, x=0, y=0,
    width=17, height=13) at xutil.c:229
#7  0xbd1c89b7 in _i_XGGState_Ops_DPSimage___________ (self=0x83f6e08,
    _cmd=0xbd1e18d8, matrix=0x8404d08, pixelsWide=17, pixelsHigh=13,
    bitsPerSample=8, samplesPerPixel=4, bitsPerPixel=32, bytesPerRow=68,
    isPlanar=0 '


_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Follow-up Comment #3, bug #20453 (project gnustep):

I had a close look at the back trace and this looks rather normal to me. A
window gets displayed from the main thread redisplay mechanism. Here I can't
even tell whether a second thread is involved. What I don't see in you back
trace is the reported problem. It cannot be the problem you posted in the
original bug report (Uncaught exception NSInvalidArgumentException, reason:
Tried to add nil to array) as the back trace is already on the X window level
and this is a GNUstep message.
Could it be that you have a second thread running and posted the back trace
from the wrong thread?

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Follow-up Comment #4, bug #20453 (project gnustep):

I tried to reproduce this on FreeBSD (so a different OS).Here I get a freeze
without getting an exception panel, so it is different, but it happens when
doing the same things. DOes this trace make more sense to you?

#0  0x28bd1888 in XAddExtension () from /usr/local/lib/libX11.so.6
#1  0x28d27ffa in _XftDisplayInfoGet () from /usr/X11R6/lib/libXft.so.2
#2  0x28d2c5ee in XftFontLoadGlyphs () from /usr/X11R6/lib/libXft.so.2
#3  0x28d2a27f in XftGlyphExtents () from /usr/X11R6/lib/libXft.so.2
#4  0x28d2a633 in XftTextExtents32 () from /usr/X11R6/lib/libXft.so.2
#5  0x28d04803 in -[GSXftFontInfo(Private) xGlyphInfo:] (self=0x8423e08,
    _cmd=0x28d20928, glyph=43) at GSXftFontInfo.m:726
#6  0x28d03a24 in -[GSXftFontInfo advancementForGlyph:] (self=0x8423e08,
    _cmd=0x28404be8, glyph=43) at GSXftFontInfo.m:330
#7  0x282fbee3 in -[GSHorizontalTypesetter layoutLineNewParagraph:] (
    self=0x8356408, _cmd=0x28404cc0, newParagraph=1 '


_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Follow-up Comment #5, bug #20453 (project gnustep):

Again a pretty normal back trace without a sign of a problem :-)
What is also needed is the error you get. Only then is it possible to tell,
whether that error is related to the back trace or if there is another thread
involved, which causes the actual problem.

Why should your X system freeze when asking for a text extent? Even when we
have unsupported characters there, it should report an error and not freeze.
Perhaps it would help, if you added a log statement to xGlyphInfo:, but be
warned, this will produce a lot (really a lot) of output.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Follow-up Comment #6, bug #20453 (project gnustep):

Does this problme still persist? If so, could you please add some more
information?



    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Follow-up Comment #7, bug #20453 (project gnustep):

Here is a backtrace from FTP.

The attached sample program reproduces the issue.   I believe that it is
caused by the run loop and the spawned thread attempting to update the
graphics context at the same time.   Should we consider having locks in those
methods to prevent this type of thing occurring for multi threaded apps?


719       _terminate();
(gdb) bt
#0  0x55ed6327 in raise () from /lib/tls/libc.so.6
#1  0x55ed7b75 in abort () from /lib/tls/libc.so.6
#2  0x55ad762c in _terminate () at NSException.m:692
#3  0x55ad78cd in _NSFoundationUncaughtExceptionHandler
(exception=0x5700a100)
    at NSException.m:719
#4  0x55ad80a0 in -[NSException raise] (self=0x5700a100, _cmd=0x558a7360)
    at NSException.m:859
#5  0x5562544f in _NSAppKitUncaughtExceptionHandler (exception=0x5700a100)
    at NSApplication.m:123
#6  0x55ad8095 in -[NSException raise] (self=0x5700a100, _cmd=0x55ddbd80)
    at NSException.m:850
#7  0x55ad7af2 in +[NSException raise:format:arguments:] (self=0x55ddb7e0,
    _cmd=0x55ddbd68, name=0x55ddb55c, format=0x55db3f60,
    argList=0x56fa75b0 "0À211UØaAbØuúV§ækU200e") at NSException.m:762
#8  0x55ad7a2a in +[NSException raise:format:] (self=0x55ddb7e0,
    _cmd=0x55db49a0, name=0x55ddb55c, format=0x55db3f60) at
NSException.m:748
#9  0x55a22d83 in -[GSMutableArray addObject:] (self=0x570061a0,
    _cmd=0x558df010, anObject=0x0) at GSArray.m:411
#10 0x556bf0d2 in +[NSGraphicsContext saveGraphicsState] (self=0x558debc0,
    _cmd=0x55936ce8) at NSGraphicsContext.m:269
#11 0x5579ffaa in -[NSView _lockFocusInContext:inRect:] (self=0x835a978,
    _cmd=0x55936d78, ctxt=0x82b2058, rect=
        {origin = {x = 0, y = 0}, size = {width = 170, height = 22}})
---Type <return> to continue, or q <return> to quit---
    at NSView.m:1928
#12 0x557a208b in -[NSView displayRectIgnoringOpacity:inContext:] (
    self=0x835a978, _cmd=0x55936dd8, aRect=
        {origin = {x = 0, y = 0}, size = {width = 170, height = 22}},
    context=0x82b2058) at NSView.m:2391
#13 0x557a1dc6 in -[NSView displayRectIgnoringOpacity:] (self=0x835a978,
    _cmd=0x55936dc8, aRect=
        {origin = {x = 0, y = 0}, size = {width = 170, height = 22}})
    at NSView.m:2338
#14 0x557a19ce in -[NSView displayIfNeededInRectIgnoringOpacity:] (
    self=0x835a978, _cmd=0x55936db8, aRect=
        {origin = {x = 0, y = 0}, size = {width = 170, height = 22}})
    at NSView.m:2270
#15 0x557a1b7e in -[NSView displayIfNeededInRectIgnoringOpacity:] (
    self=0x82b2528, _cmd=0x55936db8, aRect=
        {origin = {x = 0, y = 0}, size = {width = 455, height = 347}})
    at NSView.m:2295
#16 0x557a1b7e in -[NSView displayIfNeededInRectIgnoringOpacity:] (
    self=0x828cd20, _cmd=0x55936db8, aRect=
        {origin = {x = 0, y = 0}, size = {width = 457, height = 379}})
    at NSView.m:2295
#17 0x557a1846 in -[NSView displayIfNeededInRect:] (self=0x828cd20,
    _cmd=0x55936db0, aRect=
---Type <return> to continue, or q <return> to quit---
        {origin = {x = 0, y = 0}, size = {width = 457, height = 379}})
    at NSView.m:2248
#18 0x557a1704 in -[NSView displayIfNeeded] (self=0x828cd20,
_cmd=0x5593d800)
    at NSView.m:2230
#19 0x557b4f61 in -[NSWindow displayIfNeeded] (self=0x828cc28,
_cmd=0x8056e30)
    at NSWindow.m:2226
#20 0x0804af4d in -[AppController setTransferBegin::] (self=0x8364818,
    _cmd=0x80585d8, name=0x822fb18, size=7968532) at AppController.m:374
#21 0x0804dbb6 in -[FtpClient retrieveFile:to:beingAt:] (self=0x8390cf0,
    _cmd=0x8056e08, file=0x828cba0, localClient=0x840d698, depth=0)
    at ftpclient.m:385
#22 0x0804a846 in -[AppController performRetrieveFile:] (self=0x8364818,
    _cmd=0x8056dd8, parameters=0x0) at AppController.m:278
#23 0x55b21a2b in -[NSObject performSelector:withObject:] (self=0x8364818,
    _cmd=0x55e06718, aSelector=0x8056dd8, anObject=0x0) at NSObject.m:1947
#24 0x55b86490 in -[NSThread main] (self=0x8318f98, _cmd=0x55e06728)
    at NSThread.m:858
#25 0x55e83850 in __objc_thread_detach_function (istate=0x8232330)
    at /home/heron/Development/gcc-4.1.2/libobjc/thr.c:106
#26 0x55e66927 in start_thread () from /lib/tls/libpthread.so.0
#27 0x55f68e8e in clone () from /lib/tls/libc.so.6
(gdb) up


(file #15139)
    _______________________________________________________

Additional Item Attachment:

File name: GuiTest.tgz                    Size:10 KB


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Update of bug #20453 (project gnustep):

                  Status:                    None => Confirmed              

    _______________________________________________________

Follow-up Comment #8:

Yes, this looks like a background thread is trying to draw. The error message
that you did not attach should be something like "Trying to add nil to an
array", is this correct?

Now we have the convention in GNUstep that only the main thread is allowed to
do any drawing. We would need more then just a few locks to work around this
restriction. What a background process should do is call [NSView
setNeedsDisplay:] instead of [NSWindow displayIfNeeded].

I just checked with the Cocoa specification and they are doing things
differently there:

http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaDrawingGuide/GraphicsContexts/chapter_3_section_5.html

They even recomment not to use setNeedsDisplay: on a secondardy thread, but
in GNUstep we have special code in there to get this working.

The simplest way I see to work around the traceback will be to make
NSGraphicsContext's class methods save against not having a current context.
But of course we will then run into issues with one thread adding a context to
the stack and another removing it. Better keep the drawing just in one thread
for now.



    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Markus Hitter]

Am 04.03.2008 um 00:13 schrieb Fred Kiefer:

> What a background process should do is call [NSView
> setNeedsDisplay:] instead of [NSWindow displayIfNeeded].

That's valid for any drawing process/task, btw.. The -display...  
methods shouldn't be used at all.




_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Follow-up Comment #9, bug #20453 (project gnustep):

Since the documentation recommends against the precise behavior of the test
case that was submitted and since removing the displayIfNeeded, etc calls from
the FTP.app program (which was having this issue) seems to have corrected the
issue I believe that this bug can be closed.

GJC

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Follow-up Comment #10, bug #20453 (project gnustep):

FTP no longer makes GUI calls from the secondary thread, so the application
is fixed, should we close the bug until another person attempts the same?

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[Paul D. Smith]

Update of bug #20453 (project gnustep):

                  Status:               Confirmed => Wont Fix              
             Open/Closed:                    Open => Closed                

    _______________________________________________________

Follow-up Comment #11:

Closed as requested by original author

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@...
http://lists.gnu.org/mailman/listinfo/bug-gnustep