Issue fixed in 4.2.5. Kindly upgrade the Sourcetree Version and verify.

Same effect here. I Wish opening FileMerge would not crash SourceTree or make both FileMerge and SourceTree hang..

That very well may be accurate.  Beyond Compare has installable command-line tools which launch the UI app.  It would be nice if SourceTree improved the behavior in general for all diff tools including FileMerge to benefit.  One thing that makes me think this issue may not simply be SourceTree waiting for the process to complete, is that at least in my experience, the hang is very unpredictable.  Occasionally SourceTree doesn't hang at all when launching FileMerge, and it often doesn't hang immediately.  I'm often able to continue using SourceTree for a few seconds or longer after FileMerge is launched.  If SourceTree intends to always wait for the diff to complete, it's definitely not doing this very cleanly.  The hang is unpredictable, there's no indication to the user of what's happening, and it not only blocks user interaction but becomes completely unresponsive to the OS.  I believe that ideally either SourceTree should never block, or should give the user the option, especially for diff'ing which is generally a read-only operation.  But at the very least it should behave more predictably.

It doesn't repro with my preferred diff tool which is Beyond Compare.

The difference may be that your tool detaches from its parent somehow (there are several ways how this can happen), so for SourceTree it looks like your process is done and thus it won't block any longer, whereas FileMerge clearly doesn't do that. A simple way how this may happen is that your tool may offer a command line app, which then starts the UI app, however, the command line app doesn't wait for the UI app to quit but quits as soon as the UI app has started. For SourceTree this looks as if your tool is done processing, it cannot know that it spawned another child (you have no access to grandchildren).

The issue is specific to the integration of SourceTree and FileMerge.  It doesn't repro with my preferred diff tool which is Beyond Compare.  So, it's certainly possible for SourceTree to work better in general.  I also launch Beyond Compare as a SourceTree custom diff tool in read-only mode (passing argument "-ro") which avoids any of the potential sorts of issues discussed above.  I haven't tested any other diff tools with SourceTree.

Yeah, thats a good point. Would it be feasable to have SourceTree detect that a diff is open but only block (and notify the user) when it detects that the diff has been modified, such as after the first ctrl-S (so as to prevent conflicts)? I feel like this provides the best functionality without creating a frustrating/annoying user experience.

That explanation is reasonable for merging, although as DeveloperACE says it would be very nice to have an indication that this is intentional.

However I came across the bug not while merging but simply viewing diffs. There is no reason I can see that SourceTree cannot so other things while diffs are being viewed. Please correct me or explain if I am mistaken.

MacHG, for example, is able to remain unblocked while viewing diffs, which makes it very convenient for lining up code reviews or comparing multiple changesets.

When I first came across this, I thought it was unexpected behavior because sourcetree gave no indication that it was doing this, which is what led me to thinking it was a bug. Your explanation makes total sense as to why it would do this, so I think it it would be nice to pop up some kind of warning or notification screen to let the user know that the behavior is a feature to prevent conflicts and not a bug.

SourceTree needs to know when you are done with "merging". When you start an external process, the only information that you as parent process are guaranteed to receive is the information that your child process has just died, as well as its exit code. Thus SourceTree waits until the process has died, knowing for sure that you are done merging when this happens, and to prevent any data race conditions, it blocks until this has happened.

How else would you like SourceTree to work?

Unblock when you close the FileMerge window? SourceTree won't be informed when you close that window. Monitoring windows of another process is not easily possible (SourceTree would have to register as an Accessibility Helper process, requiring the user to authenticate SourceTree for this task and then using the Accessibility API it would be possible to retrieve a list of Windows from another process, albeit still very complex).

Monitoring the merged file for changes? Just because you hit CMD-S and FileMerge and save the current merge output doesn't mean you are done merging, as you can still make changes and hit CMD-S again. SourcTree cannot continue until it knows for sure that you are done and monitoring the file for changes simply won't tell it whether you are done or not.

Also appears on Sourcetree 2.4.1 on Mac OS X 10.11.6. my observation is that source tree freezes as long as filemerge is open but i may be wrong