[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EasyDiff on windows crash
From: |
Riccardo Mottola |
Subject: |
Re: EasyDiff on windows crash |
Date: |
Fri, 10 Aug 2012 17:58:46 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11 |
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