gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Odd problem with NSSavePanel


From: Germán Arias
Subject: Re: Odd problem with NSSavePanel
Date: Fri, 10 Jan 2014 23:57:06 -0600
User-agent: GNUMail (Version 1.2.1)

Thanks Fred, now works.

Germán.

On 2014-01-10 10:59:43 -0600 Fred Kiefer <address@hidden> wrote:

> Should be fixed now. Please give it a try.
> 
> Fred
> 
> On 10.01.2014 16:50, Fred Kiefer wrote:
>> Hi German,
>> 
>> I think I understand the problem now and it is only in NSSavePenl, not
>> in your application. When the save panel has already been used it holds
>> a value in the instance variable _fullFileName. When a document without
>> a name gets save the save panel method runModal gets called, which calls
>> [self filename] which sometimes just returns _fullFileName. Next [self
>> _setupForDirectory: path file: filename] gets called with this value and
>> the this line resets the instance variable:
>> 
>> ASSIGN(_fullFileName, [_directory stringByAppendingPathComponent:
>> filename]);
>> 
>> Now as filename is actually _fullFileName it will get released and any
>> usage of this variable later on will lead to the segmentation fault you
>> are getting. And this happens just two lines later.
>> 
>> Now the correct solution is to return an autorelease copy from the
>> filename method, as I already expected. But one other questions gets
>> raised by this, where should we use file names including directories and
>> where just a simple file name? This seems to be wrong as well.
>> 
>> Fred
>> 
>> On 09.01.2014 09:15, Fred Kiefer wrote:
>>> Hi German,
>>> 
>>> I did some investigations into this myself but didn't write about it,
>>> as I couldn't pin down the issue. I don't think the filename is empty
>>> when the code crashes. Rather it is filled with an already released
>>> value. You may check that in gbd, the variable has a value but
>>> dereferencing it crashes gdb. Most likely the release happens outside
>>> of the save panel, otherwise we would have the problem with all
>>> document applications. At least we should protect the save panel
>>> against this by returning a copy from that method. I hope to find
>>> time for this tomorrow.
>>> 
>>> Fred
>>> 
>>> On the road
>>> 
>>> Am 09.01.2014 um 08:07 schrieb Germán Arias <address@hidden>:
>>> 
>>>> Well, after some research I'm more confused. I'm not sure, but I
>>>> think that _fullFileName and _allowedFileTypes are involved in
>>>> this problem. At some moment these variables don't store anything.
>>>> So, the method -filename don't return anything, and call -length
>>>> over the returned value crashed the program.
>>>> 
>>>> The other problem I see is that _fullFileName depends of returned
>>>> value from -filename. You can see this at line 608 on
>>>> NSSavePanel.m. The parameter filename is the returned value of
>>>> -filename (see method -runModal). At line 608, what happen when
>>>> pass a parameter that don't contains anything?
>>>> 
>>>> Furthermore, I noticed other strange problem with SavePanel. For
>>>> example: launch Ink, write something at the document and save this.
>>>> Now close the document and creates a new one. Write something in
>>>> this new document and save this. If you notice, the save panel puts
>>>> the full path of previous saved document. See attached image. Why
>>>> do this the panel?
>>>> 
>>>> <savepanel.jpg>
>>>> 
>>>> 
>>>>> On 2014-01-07 12:45:58 -0600 Germán Arias <address@hidden>
>>>>> wrote:
>>>>> 
>>>>> I'm having a problem with Gemas and NSSavePanel. You can
>>>>> reproduce it with these steps:
>>>>> 
>>>>> * Launch Gemas. * Create a new file of type "Other" (Document ->
>>>>> New File -> Other). * Write something. * Save the file (don't add
>>>>> an extension). * Close the document. * Create a new file of type
>>>>> "Other". * Write something. * Try to save this, the app crash.
>>>>> 
>>>>> At GemasInfo.plist the extension of this type is described as ( *
>>>>> ), this is any file. And this problem only occurs with types that
>>>>> have its extension like this one.
>>>>> 
>>>>> Here the backtrace:
>>>>> 
>>>>> (gdb) backtrace #0  0x00a992c6 in objc_msg_lookup () from
>>>>> /usr/lib/i386-linux-gnu/libobjc.so.3 #1  0x0032866b in
>>>>> -[NSSavePanel(PrivateMethods) _selectCellName:] ( self=0x82bfa28,
>>>>> _cmd=0x55f520, title=0x8548ea0) at NSSavePanel.m:528 #2
>>>>> 0x00328af5 in -[NSSavePanel(PrivateMethods) _setFileName:] ( 
>>>>> self=0x82bfa28, _cmd=0x55f588, filename=0x8548ea0) at
>>>>> NSSavePanel..m:587 #3  0x00328d13 in
>>>>> -[NSSavePanel(PrivateMethods) _setupForDirectory:file:] ( 
>>>>> self=0x82bfa28, _cmd=0x55f1b0, path=0x821c928,
>>>>> filename=0x8548ea0) at NSSavePanel.m:610 #4  0x00329c8d in
>>>>> -[NSSavePanel runModalForDirectory:file:] (self=0x82bfa28, 
>>>>> _cmd=0x55f6a0, path=0x821c928, filename=0x8548ea0) at
>>>>> NSSavePanel..m:1140 #5  0x00329ba6 in -[NSSavePanel runModal]
>>>>> (self=0x82bfa28, _cmd=0x518e10) at NSSavePanel.m:1111 #6
>>>>> 0x00285fbb in -[NSDocument runModalSavePanel:withAccessoryView:]
>>>>> ( self=0x837c278, _cmd=0x518ef0, savePanel=0x82bfa28, 
>>>>> accessoryView=0x84c4f68) at NSDocument.m:1088 #7  0x00289be7 in
>>>>> -[NSDocument _runSavePanelForSaveOperation:] ( self=0x837c278,
>>>>> _cmd=0x518ef8, saveOperation=NSSaveOperation) at
>>>>> NSDocument.m:1203 #8  0x00286319 in -[NSDocument 
>>>>> runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo:]
>>>>>   (self=0x837c278, _cmd=0x519020, saveOperation=NSSaveOperation,
>>>>> delegate=0x0, didSaveSelector=0x0, contextInfo=0x0) at
>>>>> NSDocument.m:1229 #9  0x0028745d in -[NSDocument 
>>>>> saveDocumentWithDelegate:didSaveSelector:contextInfo:]
>>>>> (self=0x837c278, _cmd=0x519018, delegate=0x0,
>>>>> didSaveSelector=0x0, ---Type <return> to continue, or q <return>
>>>>> to quit--- contextInfo=0x0) at NSDocument.m:1564 #10 0x002872c1
>>>>> in -[NSDocument saveDocument:] (self=0x837c278, _cmd=0x8147910, 
>>>>> sender=0x83080e0) at NSDocument.m:1524 #11 0x0020ce97 in
>>>>> -[NSApplication sendAction:to:from:] (self=0x81253f8, _cmd=0x53ef50, 
>>>>> aSelector=0x8147910, aTarget=0x0,
>>>>> sender=0x83080e0) at NSApplication.m:2230 #12 0x002e2c64 in
>>>>> -[NSMenu performActionForItemAtIndex:] (self=0x8302618, _cmd=0x5420a0, 
>>>>> index=4) at NSMenu.m:1323 #13 0x002ecb6a in
>>>>> -[NSMenuView _trackWithEvent:startingMenuView:] ( self=0x8309300,
>>>>> _cmd=0x542118, event=<optimized out>, mainWindowMenuView=0x0) at
>>>>> NSMenuView.m:1916 #14 0x002eb113 in -[NSMenuView trackWithEvent:]
>>>>> (self=0x8309300, _cmd=0x542188, event=0x833e558) at
>>>>> NSMenuView.m:1948 #15 0x002eb414 in -[NSMenuView mouseDown:]
>>>>> (self=0x8309300, _cmd=0x59fff0, theEvent=0x833e558) at
>>>>> NSMenuView.m:1988 #16 0x003d6724 in -[NSWindow sendEvent:]
>>>>> (self=0x8308630, _cmd=0x4eaf40, theEvent=0x833e558) at
>>>>> NSWindow.m:3896 #17 0x00211f7b in -[NSApplication sendEvent:]
>>>>> (self=0x81253f8, _cmd=0x4eae78, theEvent=0x833e558) at
>>>>> NSApplication.m:2105 #18 0x002144eb in -[NSApplication run]
>>>>> (self=0x81253f8, _cmd=0x4e1348) at NSApplication.m:1562 #19
>>>>> 0x001f1f0f in NSApplicationMain (argc=1, argv=0xbfffe404) at 
>>>>> Functions.m:91 #20 0x08048fe7 in main (argc=1, argv=0xbfffe404)
>>>>> at Gemas_main.m:26
>>>>> 
>>>>> Any advice?
>>>>> 
>>>>> Thanks. Germán.
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]