SegFault of CommitMonitor on Windows Shutdown
Monitor your SVN repositories and notifies you on new commits
Brought to you by:
steveking
Originally created by: ole.tren...@gmail.com
Originally owned by: tortoisesvn
What steps will reproduce the problem?
1. Run CommitMonitor
2. Shutdown Windows
What is the expected output? What do you see instead?
Usually the application should quit silently. Instead it tries to access
some invalid memory address, resulting in a Windows error message and thus
interrupting the shutdown.
See http://img.i7m.de/images/8frkh-ja7fb-9f1aa-8ulm27.jpg or attached
screenshot.
What version of the product are you using? On what operating system?
CommitMonitor 1.4.0.354 on Windows XP Professional SP3
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tortoisesvn
Some questions:
* does it crash too if you use the "exit" button in the main dialog?
* exit CM, make a copy of the %APPDATA%\CommitMonitor\urls file, then remove the
original urls file, start CM and add your projects again - does that maybe fix the
crashes? If yes, it would help if you could send me the original urls file (the one
you made a copy of).
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: ole.tren...@gmail.com
> does it crash too if you use the "exit" button in the main dialog?
No, it doesn't. Only and always when Windows is shut down.
> [recreate urls]
That helped for a short while. I removed my urls file and let CommitMonitor create a
new one. Without any project it would quit as expected on Windows Shutdown. But as
soon as I had [readded] my projects it showed the same behaviour as before.
I'll gladly send you the urls file if you could confirm that it doesn't contain
sensitive information like repository credentials. Else I'll simply create a new one
without credentials and send that to you.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tortoisesvn
If you get the crashes with a fresh start and adding the projects from scratch, the
urls file won't help :(
I guess I have to figure out another way to narrow this problem down.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: ole.tren...@gmail.com
Maybe I have narrowed it down a bit. Not sure if this is at all possible, but it
appears to be crashing only if it has been started via the integrated autostart
facility (which I guess uses some registry key). I've deactivated the autostart on
the options dialog and added a link to the autostart startmenu folder, now everything
seems to work.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tortoisesvn
Hmm - the only difference in the autostart methods is that the one 'integrated' in CM
uses the 'run' registry key instead of the autostart folder. And the difference
between those two is that those apps under the 'run' key are started earlier than the
ones in the autostart folder.
Could it be that some virus scanner is interfering here? Maybe CM gets loaded before
the virus scanner when using the run key but closed before the scanner on shutdown,
and that confuses the scanner?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: ole.tren...@gmail.com
That is very possible, I'd almost say likely. I'm using GData AVK and it actually
gets started "around" the time CommitMonitor used to get started (before I disabled
the autostart). I'll try to see if disabling the virus scanner fixes this issue. Not
sure what to do then, though :)
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: helder.magalhaes
I've also stumbled across this issue, both in version 1.4.0.354 and 1.5.1.382.
The crash displays a memory position which varies a bit. In several crashes, the
observed memory positions were:
* 0x40020019;
* 0x42020019;
* 0x50020019;
* 0x52020019.
Steps to reproduce:
I was able to reproduce the symptom without having to restart. Although it only
reproduces sometimes, can prove to be a big advantage over the restart procedure in
terms of debugging usefulness:
1. Start CommitMonitor ("/hidden" parameter seems to be irrelevant);
2. Perform a check (using context menu option or using main dialog button seems to
be irrelevant);
3. Wait that the check is ongoing;
4. Exit (again, using context menu option or closing the main dialog button seems to
be irrelevant).
Expected results:
CommitMonitor would terminate gracefully.
Actual results:
CommitMonitor sometimes crashes.
Additional details:
Due to the above steps to reproduce, I'd say that this might be caused by some thread
unsafe code being run when the application is notified to exit (either by
user-triggered exit or by the operating system when logging off or restarting).
Finally, past investigation experiments and thoughts (somehow by the order they
happened, not necessarily the best sorting) follow -- may help someone trying to
figure this out:
* Initially, I though it had to do with CommitMonitor start-up option
("Automatically start with Windows") as reported in comment 4 -- created a shortcut
in Start menu's "Startup" folder with no effect;
* The option "Notify when updates for CommitMonitor are available" was also disabled
without any effect;
* I also found out that a log off was enough to trigger the crash -- this makes it
more easy to reproduce the crash;
* Another hypothesis is that the "/hidden" parameter, used in the registry setting,
could be the guilty -- the start-up shortcut was modified, but experiments showed no
effect.
Some details on my current environment:
* TortoiseSVN is version 1.6.1;
* Operating system is Windows XP SP3;
* Network environment consists of a squid-based proxy;
* Anti-virus solution is Panda for Desktops 2008;
* I only have HTTP-based repositories (no HTTPS) configured;
* Six repositories are being monitored;
* One of the repositories, which is within my Intranet, has a short (30 minutes)
update interval.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tortoisesvn
(No comment was entered for this change.)
Owner: tortoisesvn
Status: Started
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tortoisesvn
Fixed in [r393].
Status: Fixed
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tortoisesvn
(No comment was entered for this change.)
Labels: Release-1.6.0
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: tortoisesvn
(No comment was entered for this change.)
Labels: -Release-1.6.0 Milestone-1.6.0
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: helder.magalhaes
Still able to experience this as of CommitMonitor 1.6.0.409. Unfortunately, as I have
no issue edit permissions, I wasn't able to reopen the issue.
What's happening is that the changes (comment 9) seemed to have fixed the behavior
during usual application exit, so in my attempts I wasn't able to reproduce the crash
using the "Check Now" followed by "Exit" (comment 7).
Nevertheless, the crash is still occurring during Log out/Shut down/Restart. The
memory positions where the crash occurs are the same as stated in comment 7. The
crash frequency is about 1/3 of times where the above actions (Log out/Shut
down/Restart) are performed, since when I've upgraded to this version of Commit Monitor.
The crash might be easier to reproduce whenever repositories are set to refresh
frequently: in my case, I'm monitoring 6 repositories, of which one (which is
Intranet-based) is set to a somehow short (30 minutes) refresh interval; the other
five (Internet-based) are set to refresh every few hours.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: helder.magalhaes
Confirmed that this is also in version 1.6.3.438, although it wasn't reopened as
asked... :-|
Steps to reproduce:
1. Log on;
2. Start CommitMonitor;
3. Hold for a few seconds (to allow the check repositories to be active);
4. Log off.
Expected result:
CommitMonitor would exit gracefully.
Actual result:
Crash in memory positions already stated (in comment 7).
Additional information:
I have a shortcut to CommitMonitor in my startup menu (using "/hidden").
I'm able to reproduce the crash in more than 50% of log off actions.