WinMerge stays in tasklist after closing

WinMerge configuration log

Logged In: YES
user_id=1568667
Originator: NO

I'm using 2.6.0 too, but it's all OK, no "lost" processes after exit.

Logged In: YES
user_id=631874
Originator: NO

This bug (or variants of it) has been reported several times, I think starting from 2.4.0 release or something like that. Most users don't see it, but it seems to be consistent for some users.

One possible reason has been plugins, some people have reported that removing plugin files from WinMerge/Plugins folder fixes the bug. But somebody reported that it didn't help for him.

Reason of the bug (in lack of any of the developers being able to reproduce it) is unknown still.

Logged In: NO

Don't work for me...

Logged In: NO

yes i've got the same problem

Logged In: YES
user_id=411238
Originator: NO

With the help of Fanny Riour, we were able to find the symptom of the problem. When WinMerge closed, CMainFrame::OnClose() is called, followed by CMainFrame::OnDestroy(). However the CMergeApp::ExitInstance() method is never called. This probably mean that somehow the WM_QUIT message got lost in the way.

I still don't know how this is possible nor how to solve it. :-(

New ideas or solutions are welcomed.

Logged In: YES
user_id=631874
Originator: NO

Greats news we now have some idea about this! Absolutely high-priority bug then.

Did you track this with released (2.6.0) codes or with latest trunk codes, as I slightly changed the closing handling in patch:
#1596692 Change the way modified docs are saved to fix several issues
That patch is in 2.7.1.2 experimental also.

Logged In: YES
user_id=411238
Originator: NO

We're working using the 2.6.0 version.

I'll look at your fix and see if it might be relevant to the bug.

Logged In: YES
user_id=631874
Originator: NO

Oh, I just noticed one thing - original submitter has WinXP *SP1*. And common controls DLL is also older than in SP2. SP2 was a huge change, basically rebuild Windows components. Other reports don't mention SP version, so this is just one possibility..

Logged In: NO

I've got the same problem on versions 2.6.2, and experimental 2.7.1.3

Fixed it in the source by adding the following line:
AfxPostQuitMessage(0);

at the end of CMainFrame::OnClose, right after the line:
CMDIFrameWnd::OnClose();

it worked well, at least for me !!

HTH,
Lago

Logged In: YES
user_id=411238
Originator: NO

Thanks for the tip, Lago. We already found that a double post of WM_QUIT message terminate WinMerge (it was posted on a similar bug item).

Solving the program the way you describe fix the symptom of the problem rather than the cause of the problem (WM_QUIT message get lost). The MFC framework is the one which is responsible for sending the message when the program is closed. If it fail it probably mean that something else is wrong.

Logged In: YES
user_id=631874
Originator: NO

Still the fact is this bug makes WinMerge look very bad for users seeing it. So for stable releases I am ready to accept these kind of solutions. Better solutions can be tested in development trunk meanwhile.

Question is if this double-post of WM_QUIT causes other side-effects for users not seeing this bug? Probably not as we are already closing down..

Yes, we have something broken in message handlers somewhere. But finding that bug doesn't seem to be easy. One thing to look at is the single-instance code. Timers I already checked. ESC-key quit code should not have effect as this bug is visible when closing WinMerge from menu.

Logged In: YES
user_id=411238
Originator: NO

> Still the fact is this bug makes WinMerge look very bad for users seeing
> it. So for stable releases I am ready to accept these kind of solutions.

Too late for 2.6.2 version. :-(

> Question is if this double-post of WM_QUIT causes other side-effects for
> users not seeing this bug? Probably not as we are already closing down..

I don't think there should be any side-effects for the double-posting this message. After all, the first one reached some other message loop, or just get lost on its way.

I have a patch ready against R2_6 branch. Want me to commit it or to update it for a review first?

Logged In: YES
user_id=631874
Originator: NO

Just for completeness and discussion, please attach/past it here first.

Logged In: YES
user_id=631874
Originator: NO

Assigning to you so you can attach the patch - feel free to assign back to nobody.

Logged In: YES
user_id=411238
Originator: NO

Attached.

I also added Fanny Ricour to the contributors list. He helped me a lot with this bug.

File Added: NotExitBug.7z

Logged In: YES
user_id=631874
Originator: NO

Looks fine.

Seems I have to release 2.6.4 pretty soon (read: first weeks of January) as seems 2.6.2 broke some file filter rules. And I forgot one patch from it.

Logged In: YES
user_id=411238
Originator: NO

You can always release 2.6.2-1 :-). There is also the "rename" bug which should be fix and probably some more.

I also need to verify (=double check) with Fanny Ricour that this patch "fix" the problem.

Logged In: YES
user_id=631874
Originator: NO

Can you apply this today, I want to release next experimental late today or tomorrow.

Logged In: YES
user_id=631874
Originator: NO

Ow, sorry, I think its still not good to apply it to trunk. But I'll apply it locally for the release so we get some testing for the patch.

So, no need to apply the patch to the SVN.

Logged In: YES
user_id=631874
Originator: NO

Experimental release hasn't caused any complaints, so I think we can apply the patch to 2.6 branch.

Logged In: YES
user_id=411238
Originator: NO

Okay. I'll just make sure there is a comment which explain the patch.

Is this patch is in trunk? I thought you applied it only to your private source tree.