Version : 188.8.131.52 (french)
Email address : fanny.ricour [at] gmail [dot] com
Whenever I close WinMerge, WinMergeU.exe stays in tasklist and keeps using memory. If I open WinMerge for a second time, two WinMergeU.exe processes are in the tasklist.
WinMerge configuration log
Logged In: YES
I'm using 2.6.0 too, but it's all OK, no "lost" processes after exit.
Logged In: YES
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...
yes i've got the same problem
Logged In: YES
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.
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 184.108.40.206 experimental also.
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.
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..
I've got the same problem on versions 2.6.2, and experimental 220.127.116.11
Fixed it in the source by adding the following line:
at the end of CMainFrame::OnClose, right after the line:
it worked well, at least for me !!
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.
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.
> 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?
Just for completeness and discussion, please attach/past it here first.
Assigning to you so you can attach the patch - feel free to assign back to nobody.
I also added Fanny Ricour to the contributors list. He helped me a lot with this bug.
File Added: NotExitBug.7z
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.
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.
Can you apply this today, I want to release next experimental late today or tomorrow.
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.
Experimental release hasn't caused any complaints, so I think we can apply the patch to 2.6 branch.
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.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.