Jim Brodrick wrote:
> I am sorry that you had problems installing ER/Studio when
> tortoisesvn is installed. We are aware of this problem, and it is
> caused by the same issue I reported below. If I had known you were
> going to download ER/Studio I would have let you know about this.
Well, you reported a problem with TSVN and your app. How should I
reproduce the problem and find out the reason without actually
installing your app?
> I have identified the cause of the crash. It does not have so much
> to do with your product being a shell extension as it does with the
> fact that your product injects itself into the process context of
> ER/Studio at load time. If you look carefully at the dependency
> walker trace, you'll see that the dll init function of
> libapr_tsvn.dll was executing when both the stack overflow and the
> subsequent crash occurred.
That's correct. But see below.
> After looking at dependency walker traces for loading the previous
> version of er/studio, I found that your dlls are linked to
> msvcr80.dll and msvcp80.dll. The crash appears to happen because the
> dll init routine in libapr_tsvn.dll crashes when the init routines
> for one or both of the msvc dlls have not already run to completion.
> We updated to a new version of a third party dll that is also linked
> to these dlls in the latest er/studio version. In this load
> configuration the msvc dll init routines are not called before the
> one in the above-mentioned dll. I fixed the crash by forcing the
> third-party dll (and thus the msvc dlls) to load sooner.
This will not really solve your problem! All you did was reduce the
required stack size by avoiding the load of the version 7.1 c-runtime.
But as soon as one of your users has another shell extension which is
linked against that c-runtime, you'll have the same problem again.
That's not a solution!
I can't believe I have to explain this to a software company which sells
an expensive piece of software. I would expect you and your developers
to know this:
You must increase the stack size of your application! Because right now,
you have a too small stack size for your needs. Sure, it works as long
as almost no shell extensions are installed. But since you load the
shell (almost every app does, using a file-open or file-save dialog is
enough), you have to take into account that not only the shell itself
but all the extensions of the shell also need some stack, and your stack
must be big enough for those too.
The 'stack overflow' should have been enough for you to discover this.
> I realize that this is a complex loading scenario, but it seems that
> NT doesn't guarantee that the init routines of dependent dlls will
> run first in all cases. Since your dlls inject themselves into other
> process contexts, it would appear that the dll init routines need to
> handle cases like this.
Yes, NT *does* guarantee that, as long as it *can* do it (i.e. the stack
is big enough). But if the stack is not big enough, the only thing it
can do is stop and error out.
Oh, btw: there still are some shell extensions out there written in .NET
(which is something completely 'illegal', but still, people do it
anyway). If one of your users has only one of those installed, your app
will break big time: the .NET framework uses a *lot* of stack space.
Stefan
P.S. I think next time I should ask for a consulting fee - after all I
had to tell you how to fix *your* app :)
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Tue May 1 19:55:11 2007