#1390 WinMerge stays in tasklist after closing

Branch_+_Trunk
closed-duplicate
Usability (119)
7
2014-08-14
2006-11-24
Anonymous
No

Version : 2.6.0.0 (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.

Discussion

1 2 > >> (Page 1 of 2)
  • Nobody/Anonymous

    WinMerge configuration log

     
  • Rumi

    Rumi - 2006-11-24

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-11-24

    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.

     
  • Nobody/Anonymous

    Logged In: NO

    Don't work for me...

     
  • Nobody/Anonymous

    Logged In: NO

    yes i've got the same problem

     
  • Gal Hammer

    Gal Hammer - 2006-11-29

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-11-29

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-11-29
    • milestone: --> Branch_+_Trunk
    • priority: 5 --> 7
     
  • Gal Hammer

    Gal Hammer - 2006-11-29

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-12-05

    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..

     
  • Nobody/Anonymous

    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

     
  • Gal Hammer

    Gal Hammer - 2006-12-17

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-12-17

    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.

     
  • Gal Hammer

    Gal Hammer - 2006-12-18

    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?

     
  • Kimmo Varis

    Kimmo Varis - 2006-12-18

    Logged In: YES
    user_id=631874
    Originator: NO

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

     
  • Kimmo Varis

    Kimmo Varis - 2006-12-18

    Logged In: YES
    user_id=631874
    Originator: NO

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

     
  • Kimmo Varis

    Kimmo Varis - 2006-12-18
    • assigned_to: nobody --> galh
     
  • Gal Hammer

    Gal Hammer - 2006-12-18
     
  • Gal Hammer

    Gal Hammer - 2006-12-18

    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

     
  • Kimmo Varis

    Kimmo Varis - 2006-12-18

    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.

     
  • Gal Hammer

    Gal Hammer - 2006-12-18

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2006-12-19

    Logged In: YES
    user_id=631874
    Originator: NO

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

     
  • Kimmo Varis

    Kimmo Varis - 2006-12-19

    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.

     
  • Kimmo Varis

    Kimmo Varis - 2007-01-10

    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.

     
  • Gal Hammer

    Gal Hammer - 2007-01-10

    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.

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks