bugGNUstep - Bugs: bug #24200, NSSavePanel crashes apps

Group
 
 

bug #24200: NSSavePanel crashes apps

Submitter:  Niels Grewe <thebeing>
Submitted:  Thu 04 Sep 2008 10:04:10 AM UTC
   
 
Category:  Gui/AppKit Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 08 Sep 2008 08:35:55 PM UTC, comment #3: 

I just compiled and can confirm that the change fixed the issue for me, both with GSX11HandlesWindowDecorations set to Yes and No. Besides, I can't really see any use of setting GSSavePanelShowProgress to yes on my machine since it neither has large enough directories nor contrained enough resources, so I can't comment on whether the changed string gets drawn.

Cheers,


Niels

Niels Grewe <thebeing>
Group Member
Mon 08 Sep 2008 07:29:47 PM UTC, comment #2: 

I just replaced the calls to  [GSCurrentContext() flushGraphics] with [self flushWindow], this should work more reliable. Still when the window decoration is drawn by GNUstep we have no garanty that the changed string will get displayed.

Fred Kiefer <FredKiefer>
Group Member
Fri 05 Sep 2008 08:54:54 PM UTC, comment #1: 

The line [GSCurrentContext() flushGraphics]; is used in the NSSavePanel to display progress information on big directories.
This only happends when explicitly requested by setting the property GSSavePanelShowProgress to YES. So the simplest solution will be to set this to NO in your defaults file.

For a general solution we will have to find out where the problem actually happends and decide how to resolve it. I think that here a wrong context gets found as the current context. (Although in most cases the current context will be the application context and I see no reason, why this could be wrong)
Independent of this we should rethink, whether a flush is the right think to do here. We are setting the window title to display the progress and when GNUstep is displaying the window decoration itself the flush is even before the system gets a chance to draw anything. Perhaps it would be best to remove the whole feature? Or replace the flush by a way to get the run loop do its job while loading huge amounts of cells?

Fred Kiefer <FredKiefer>
Group Member
Thu 04 Sep 2008 10:04:10 AM UTC, original submission:  

Hello,

I am experiencing segmentation faults with GNUstep trunk on Debian unstable x86-64 whenever an application tries to create a NSSavePanel (according to gdb backtrace) and would like to ask for advice on what might be causing this. It happens with both the cairo and the art backend. I have attached a backtrace from running and crashing Gorm, but the problem occurs with other applications (ProjectCenter, EasyDiff) too. I hope it will be usefull.

best regards,


Niels

Relevant versions:
base,gui,back: svn r26830
cairo: 1.6.4
libart:  1.4.2


Niels Grewe <thebeing>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #16430:  gorm-backtrace added by thebeing (7KiB - application/octet-stream - Backtrace from running Gorm)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by thebeing (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-11-29 FredKiefer StatusReady For Test Fixed
        Open/ClosedIn Test Closed
    2008-09-08 FredKiefer StatusNone Ready For Test
        Assigned toNone FredKiefer
        Open/ClosedOpen In Test
    2008-09-04 thebeing Attached File- Added gorm-backtrace, #16430

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code