Crash in history view with specific repository

Issue #13 resolved
John Gee
created an issue

I have a test repository created from cvs via svn with 61500 Mercurial revisions, to see how useful keeping all the history might be. When I switch to the history view, MacHg crashes.

Initially the crash was in LogTableView:resetTable but I added an NSAutoreleasePool into the loop adding objects to newTableRows, which allowed resetTable to complete.

This stack is from the next crash

{{{
(gdb) continue
2010-05-07 10:49:29.977 MacHg[59438:a217] An uncaught exception was raised
(gdb) continue
2010-05-07 10:49:29.997 MacHg[59438:a217] -[NSCFString replaceCharactersInRange:withString:]: nil argument
2010-05-07 10:49:33.086 MacHg[59438:a217]
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: ' -[NSCFString replaceCharactersInRange:withString:]: nil argument'
Call stack at first throw:
(
0 CoreFoundation 0x00007fff813c2d24 exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff855460f3 objc_exception_throw + 45
2 CoreFoundation 0x00007fff813c2b47 +[NSException raise:format:arguments:] + 103
3 CoreFoundation 0x00007fff813c2ad4 +[NSException raise:format:] + 148
4 Foundation 0x00007fff81533522 mutateError + 167
5 Foundation 0x00007fff814e6b71 -[NSConcreteMutableAttributedString replaceCharactersInRange:withAttributedString:] + 320
6 MacHg 0x0000000100024bab -[Sidebar informationTextViewMessage:] + 406
7 MacHg 0x0000000100025059 -[Sidebar updateInformationTextView] + 83
8 MacHg 0x0000000100022cd6 -[Sidebar logEntriesDidChange:] + 229
9 Foundation 0x00007fff8149886e _nsnote_callback + 167
10 CoreFoundation 0x00007fff8136aaea
CFXNotificationPost + 954
11 CoreFoundation 0x00007fff81357098 _CFXNotificationPostNotification + 200
12 Foundation 0x00007fff8148f7d8 -[NSNotificationCenter postNotificationName:object:userInfo:] + 101
13 MacHg 0x00000001000080de -[NSObject(NSObjectPlusObservations) postNotificationWithName:userInfo:] + 82
14 MacHg 0x000000010006b9c0 __-[RepositoryData updateOpenHeadParts]_block_invoke_1 + 988
15 libSystem.B.dylib 0x00007fff86cdc610 _dispatch_call_block_and_release + 15
16 libSystem.B.dylib 0x00007fff86cbabb1 _dispatch_worker_thread2 + 239
17 libSystem.B.dylib 0x00007fff86cba4e8 _pthread_wqthread + 353
18 libSystem.B.dylib 0x00007fff86cba385 start_wqthread + 13
)
terminate called after throwing an instance of 'NSException'
Program received signal: “SIGABRT”.
No memory available to program now: unsafe to call malloc

}}}

Comments (10)

  1. Jason Harris repo owner

    But the project is garbage collected... It needs garbage collection. So I don't understand the comment at all about the NSAutoreleasePool. This should not be necessary at all under any circumstances that I am aware of. 61000 changesets isn't all the large I regular test it with 250,000 and its quite quick...

    1. Can you reproduce this crash always?
    2. Is this with the downloaded MacHg or the one you have built?
    3. Can I get access to this repository?

    But thanks for the report! Cheers, Jas

  2. Anonymous

    (The NSAutoReleasePool may be a red herring as I wasn't thinking of garbage collection and put a pool allocation inside the crashing loop, but it did change the crash!)

    1. I can always reproduce the crash.
    2. With both the downloaded Hg and the one I build.
    3. Unfortunately I can't give you this particular repository.

    I am pleased to hear that 61000 changesets is not big. Trying another repository... Worked fine with 61000 revisions! What is different...

    Ok, my bug title is completely bogus but I have not pinned down the issue yet.

    MacHg works fine on a clone of the problem repository, but crashes opening the original. This original repository was created using import from svn and has not been modified since. It isn't as simple as there being no working directory, as I tried deleting the working directory from the clone but MacHg was still fine.

    Please feel free to close this bug, and I'll add another when I have a better story. I can use MacHg fine on the clone so whatever the issue is does not block me from trying out the spiffy new client!

  3. Jason Harris repo owner

    Its good to know it was not fundamentally based in NSAutoReleasePool or something! Interesting that it stopped the problem. Its good to know its reproducible. I am guessing here that the underlying repository is somehow being updated mid message there, and the message code isn't being robust enough in handling multi-threading. Thus I committed 06cd22cdc84b . Its certainly more protective code than before. Can you upgrade to this revision and try and see if that fixed the problem or just pushed it elsewhere?

    We will open this up again once we can reproduce this... Thanks! Jason

  4. John Gee reporter

    The problem seems to be trying to open a Mercurial repository freshly created using hg convert, nothing to do with the size of the repository. I created a brand new repository using these steps:

    svnadmin create svnrep
    svn checkout file://`pwd`/svnrep svnwork
    cd svnwork
    touch a.h
    svn add a.h
    svn commit -m message
    cd ..
    hg convert file://`pwd`/svnrep hgrep
    

    Dropping hgrep into latest MacHg (06cd22cdc84b) causes an exception.

    This change prevents the crash. (I have no idea what the revision being NULL actually means, or whether the fresh repository is in good state!)

    $ hg diff
    diff -r 06cd22cdc84b Classes/LogEntryModel/RepositoryData.m
    --- a/Classes/LogEntryModel/RepositoryData.m	Fri May 07 07:35:41 2010 +0200
    +++ b/Classes/LogEntryModel/RepositoryData.m	Sat May 08 00:26:21 2010 +1200
    @@ -666,7 +666,8 @@
     
     - (void) setEntry:(LogEntry*)entry
     {
    -	if (entry)
    +	if (entry && ([entry revision] != NULL))
    +//	if (entry)
     		[revisionStringToLogEntry_  synchronizedSetObject:entry forKey:[entry revision]];
     }
    
    
  5. Jason Harris repo owner
    • changed status to open

    Wow! Thanks for tracking it down in such detail. I will try and look at this in greater detail and fix it over the weekend! Before I patch Do you want to stick with the name shadowspawn as the patcher or do you want a real name in there?

    Cheers, Jas

  6. Log in to comment