Re: EasyDiff on windows crash

[Riccardo Mottola]

Hi,

Wolfgang Lux wrote:
> Nevertheless the debugger seems confused. The self argument of the -addObject: 
> method, which should be the leftLineRangesArray, is 0x4817058 while debugger 
> says leftLineRangesArray is (class NSMutableArray *) 0x184b9849. This sort of 
> thing usually happens when optimization is turned on. But anyway, given this 
> discrepancy there's no alternative to Adam's advice: single-step through the 
> program, probably from the start of DiffWrapper -initWithFilename:andFilename:.
I rebuilt with debug=yes to disable optimization and aid debuggin:

#0  -[NSException raise] (self=0x57a06ca0, _cmd=0x66ff04a8)
    at NSException.m:955
#1  0x66e705d3 in +[NSException raise:format:] (self=0x66ff02c0,
    _cmd=0x67041180, name=0x66feffe4, format=0x67041018) at 
NSException.m:835
#2  0x66f6156c in default_realloc (zone=0x67040fc0, ptr=0x401e0020,
    size=161441860) at NSZone.m:150
#3  0x66dc33f3 in -[GSMutableArray addObject:] (self=0x3b403a0,
    _cmd=0x415d10, anObject=0x57a06558) at GSArray.m:461
#4  0x0040836b in -[DiffWrapper initWithFilename:andFilename:] (
    self=0x3b56920, _cmd=0x416960, file1=0x3b0bb08, file2=0x279ec20)
    at DiffWrapper.m:70
#5  0x004097ca in -[DiffWindowController _initWithFilename:andFilename:] (
    self=0x28f8398, _cmd=0x4168f8, filename1=0x3b0bb08, 
filename2=0x279ec20)
    at DiffWindowController.m:130
#6  0x00409486 in -[DiffWindowController initWithFilename:andFilename:] (
    self=0x28f8398, _cmd=0x418dd0, filename1=0x3b0bb08, 
filename2=0x279ec20)
    at DiffWindowController.m:88

and then:
(gdb) p anObject
$1 = (id) 0x57a06558
(gdb) po anObject
89

and the array:
No symbol "leftLneRagnesArray" in current context.
(gdb) p leftLineRangesArray
$2 = (class NSMutableArray *) 0x3b403a0
(gdb) po leftLineRangesArray
[New thread 4112.0x122c]
[New thread 4112.0xe9c]
[New thread 4112.0x106c]
Program received signal SIGSEGV, Segmentation fault.

0x3b403a0 now looks consistent, right?

I put two breakpoints in DiffWrapper: one at line 53 (just after the 
allocation of the array) and one at line 70, where the exception happens.
at line 53, I get:
(gdb) p leftLineRangesArray
$1 = (class NSMutableArray *) 0x3ddae90
(gdb) po leftLineRangesArray
()

gradually, I see in line 70 the array growing. After the third iteration 
I have:
(gdb) po leftLineRangesArray
("-1", 89)
(gdb) po leftLineRangesArray
("-1", 89, 89)
(gdb) po leftLineRangesArray
("-1", 89, 89)
(gdb) p end
$3 = 89
(gdb) p length
$4 = 3258

if I print out leftString, I get the whole file. Somehow it looks stuck, 
doesn't it? I iterated manually for a dozen of times: 89.... probably at 
some point something corrupts.

If I print out "end" on Unix I get an increasing progression towards the 
whole size of the file. If I try on Windows, it gets to 89 and remains 
stuck there for infinity.
Is there a but in our getLineStart ?

I understand the code wants to progressively find all line endings by 
looking in a larger and larger range. Although I find the code strange, 
since it uses a Range of 0 length,


I rewrote the code and now it appears to work on both unix and 
windows... what do you think? I tlooks much simpler to me... "inspired" 
from the net :) It doesn't have the exceptions and it looks only in a 
specified range, it might be more efficient. Should i commit?

However, I smell an NSString bug and you?

Riccardo

easy-line.patch
Description: Text document