discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Gorm can edit which types of files ?


From: Fred Kiefer
Subject: Re: Gorm can edit which types of files ?
Date: Fri, 5 Jan 2018 16:12:37 +0100

Looks like Riccardo made some changes here but they won’t help your case. The 
problem is that line 594 in Utilities.m is still missing the check "i != 
NSNotFound“

Fred

> Am 05.01.2018 um 15:22 schrieb Daniel Santos <address@hidden>:
> 
> Hi all,
> 
> Any one has looked into this ?
> 
> Regards
> 
> On Thu, Dec 28, 2017 at 11:08 PM, Daniel Santos <address@hidden> wrote:
> I just updated libs-base and GNUMail from version-control.
> 
> doing a grep in libs-base I get :
> 
> Headers/Foundation/NSObjCRuntime.h:enum {NSNotFound = NSIntegerMax};
> 
> Which is what [aString indexOfCharacter: theSeparator]; is returning.
> 
> But because NSNotFound is NSIntegerMax : 
> 
> [aString substringWithRange: NSMakeRange(mark, i-mark)];
> 
> fails
> 
> I put a breakpoint in [NSException raise] and the trace is :
> 
> (gdb) bt 5
> #0  -[NSException raise] (self=0x555555dda9d0, _cmd=0x7ffff62c7720 
> <_OBJC_SELECTOR_TABLE+384>) at NSException.m:1136
> #1  0x00007ffff5dd87f6 in +[NSException raise:format:] (address@hidden 
> <_OBJC_Class_NSException>,
>     address@hidden <_OBJC_SELECTOR_TABLE>, name=0x7ffff62c8010 
> <_OBJC_INSTANCE_8>, address@hidden <_OBJC_INSTANCE_40>)
>     at NSException.m:1016
> #2  0x00007ffff5d420a3 in -[GSCString substringWithRange:] 
> (self=0x555555e0d0a0, _cmd=0x7ffff7dd5120 <_OBJC_SELECTOR_TABLE+2688>, 
> aRange=...)
>     at GSString.m:4107
> #3  0x00007ffff7b34053 in +[Utilities folderNodesFromFolders:separator:] 
> (self=<optimized out>, _cmd=<optimized out>, theFolders=0x5555559c4f50,
>     theSeparator=<optimized out>) at Utilities.m:602
> #4  0x00007ffff7b3470a in +[Utilities initializeFolderNodesUsingAccounts:] 
> (self=<optimized out>, _cmd=<optimized out>, theAccounts=0x555555d878c0)
>     at Utilities.m:1045
> (More stack frames follow...)
> 
> 
> 
>> On 28 Dec 2017, at 22:18, Wolfgang Lux <address@hidden> wrote:
>> 
>>> 
>>> Am 28.12.2017 um 20:00 schrieb Daniel Santos <address@hidden>:
>>> 
>>> Here are the details of the error I am getting :
>>> 
>>> The backtrace : 
>>> 
>>> (gdb) bt 5 
>>> #0  +[Utilities folderNodesFromFolders:separator:] (self=<optimized out>, 
>>> _cmd=<optimized out>, theFolders=0x555555d49e20, theSeparator=<optimized 
>>> out>)
>>>    at Utilities.m:602
>>> #1  0x00007ffff7b3470a in +[Utilities initializeFolderNodesUsingAccounts:] 
>>> (self=<optimized out>, _cmd=<optimized out>, theAccounts=0x555555e67fc0)
>>>    at Utilities.m:1045
>>> #2  0x00007fffebebce71 in -[AccountEditorWindowController 
>>> initWithWindowNibName:] (self=0x555555f5ebb0, _cmd=<optimized out>, 
>>> windowNibName=<optimized out>)
>>>    at AccountEditorWindowController.m:104
>>> #3  0x00007fffebeb764c in -[AccountViewController addClicked:] 
>>> (self=0x555555b8f990, _cmd=<optimized out>, sender=<optimized out>)
>>>    at AccountViewController.m:235
>>> #4  0x00007ffff65ad502 in -[NSApplication sendAction:to:from:] 
>>> (self=<optimized out>, _cmd=<optimized out>,
>>>    aSelector=0x7fffec0d26f0 <_OBJC_SELECTOR_TABLE+2128>, 
>>> aTarget=0x555555b8f990, sender=0x555555f68a80) at NSApplication.m:2249
>>> 
>>> in the method folderNodesFromFolders: separator: in the Utilities.m file : 
>>> 
>>> line 584
>>> i = [aString indexOfCharacter: theSeparator];
>>> aString : Drafts
>>> theSeparator : /
>>> i : 9223372036854775807
>>> 
>>> 
>>> line 602
>>> aName = [aString substringWithRange: NSMakeRange(mark, i-mark)];
>>> aString : Drafts
>>> mark : 0
>>> i : 9223372036854775807
>>> 
>>> when I step over this last instruction an exception is raised or something, 
>>> in gdb the program just continues.
>>> Obviously the substring with the range is the problem, but how does i get 
>>> that value from the indexOfCharacter method on line 584 ?
>> 
>> The problem is not so much the substringWithRange: method, but rather that 
>> the result of indexOfCharacter:, which is just NSNotFound, is not dealt with 
>> properly. This may be due to a 32/64 bit mismatch where the result of 
>> indexOfCharacter: is saved to an int variable before checking whether it is 
>> NSNotFound or perhaps the code incorrectly assumes that indexOfCharacter: 
>> returns -1 in case there is no match.
>> 
>> Wolfgang
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep




reply via email to

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