DiffMerge crash on large file

[BenM]

Hi all,

I've experienced a crash in DiffMerge a couple of times today. While it's no big deal to me, since I'm not actually losing any data, it may be worth looking into. I could not see if this has been reported elsewhere.



The crash occurs when I:
* Select a version of a moderately large source file (~9000 lines) from several revisions ago.
* Diff against the local working copy.
* Continue editing the local working copy in another editor, then save, and
* Return to DiffMerge answer Yes to reload the file, then
* mouse about to compare the old copy with the new one.

I can browse the file (scroll etc) before it prompts me to reload, and after it prompts me to reload the file but before it's fully refreshed in the view, and it generally works fine. Thus I'm not sure what user action, if any, might be at cause and I can't seem to find a way to 100% reproduce this problem.

The crash does not occur all the time, however as it's occurred a couple of times this afternoon it seemed worth throwing in the bug report.

[jeffhostetler]

Thanks for the report. I'll check into it.

If I had to guess, I'd say that it is that data structures might be
in transition during the reload and the repaints that happen as
you mouse/scroll around are referencing the incomplete data
structures. Ususally, this is not a problem, but for large data files,
the reload/rediff can take while and it's easy to click around on the
window and, say, move the caret.

That is, after the reload prompt dialog goes away and before the
new version appears, don't move the mouse, caret, or scroll and
see whether it crashes.

jeff

[BenM]

Thanks for the feedback. I'm back at work today, and back onto the same project, so I'll try what you suggest and post if it crashes again. Cheers.

[dave]

First off this is a great program. However, from a documentation/support standpoint, it would be nice to know what the upper limit is regarding the number of directories/files as well as filesize that Diffmerge can handle. I seem to be able to consistently crash, or at least cause Windows Task Manager to indicate Diffmerge is in a "Not Responding" state, when I compare two different versions of large Subversion <svn> project trunks, on the order of 200+ megabytes. If the program is indeed still grinding away at the files/directories despite the "Not Responding" state, I'd view this 'feature' as a bug, which could be fixed by displaying some more acceptable form of progress indication.

[jeffhostetler]

The "not responding" thing usually means that it's still grinding away.
This version is not multi-threaded, so it is heads-down recursively
comparing the directories. Did you actually see it crash?

There aren't any hard/fast limits -- other than the available RAM
and the various process limits.

Did you notice if the pathnames keep flashing by in the status bar?

Also, you might check the options dialog and tweak the folder window
settings.
[1] make sure that "Check for Modified...Activated" is turned off -- this
will keep it from rescanning each time you restack windows.
[2] make sure that the folder and file suffix filters are turned on and
add entries for generated items -- this will speed up the treewalk and
individual file comparisons.

Sorry I can't offer any more help right now. I have logged a bug report
for this item.

jeff

13707