Stefan Küng wrote:
> Fromm Robert wrote:
>>> So does it crash on explorer startup? Or if you view a working
>>> copy? Or if you right click on something? Or ...?
>> The explorer starts up, then it takes some time (2-3 secs) and the
>> error message appears. The explorer itself keeps running. If I right
> So maybe it's really not explorer which crashes but TSVNCache.
>> click a TortoiseSVN menu appears, but it only shows Repo-Browser,
>> settings, help and About entries. If i click on e.g. Repo-Browser the
>> same error message appears, but now for TortoiseProc. Explorer still
> TortoiseProc crashes too? I think your systems are really messed up
> somehow (no really, think about it: if TortoiseProc would crash every
> time, TSVN would be completely unusable).
>> keeps running. But on several actions - e.g. changing a directory -
>> the TSVNCache error appears. I assume TSVNCache is restarted
> Do you have a dll called crashrpt.dll in the TortoiseSVN\bin folder? If
> not, which version are you using?
>>> Do by any chance have the machines where it crashes more than one
>>> processor? Or what's different in the HW there?
>> No, all machines definitly have a single (Intel) processor. The
>> difference is, that one machine is a Notebook, the other a desktop
>> with corresponding HW.
>> I also checked for the basic SW environment in Settings/Programs. It
>> is almost the same, on the machine where TSVN is running even more is
>> Is there a possibility to provide more info to you? How can I do
> Well, if the message tells you "Die Anweisung in "0x00000000" verweist
> auf Speicher in "0x00000000" then you can't even run the debugger and
> find out something useful. A command at address 0x0000000 means that the
> program counter ran over or got overwritten (a program can *never* be
> located at that address, so somehow a jump to that address must have
> happened - and since we don't use 'goto' or something like that in C++,
> the program itself must have been overwritten somehow).
Well, it does sound like the system is hosed... but...
A stack buffer overflow could cause this by writing zero
to a functions return address slot.
A heap corruption bug could cause this by writing zero to
a function pointer (aka class vtable call slot.)
Of course these kinds of bugs are generally one of the harder
class of bugs to debug.
But given that both TSVNCache _and_ TortoiseProc are acting
up... it does seem likely that something bizarre is going
on on this system.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Sep 26 20:23:42 2005