[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Heap corruption issue seen on Japanese systems

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Tue, 04 Dec 2012 21:31:09 +0100

On 04.12.2012 15:12, Karl Nedwed wrote:
> Hello,
> I am writing on behalf of our software development group at Bio-Rad
> Laboratories. We discovered a crash in our software on a Japanese system
> that appears to point at a problem inside SVN code. Details are as follows:
> Our software (Bio-Rad KnowItAll 9.5) uses the standard File Open dialog
> box to import files into the software. On one Japanese system, there is
> a crash almost every time a user invokes the File Open dialog box. The
> Windows event log (exception code 0xc0000374) indicates a heap
> corruption, and the crash dump that you can find below also points to
> the File Open dialog box (location 0x4ec49b60 inside NT.dll).
> We did a thorough review of all relevant code in our software and could
> not find any problem. Then we noticed that Tortoise SVN (latest version
> 1.7.10) was installed on that particular system. Uninstalling it fixed
> the problem.

The stack trace does not show the involvement of TSVN.
Also, if there were a heap corruption in the TSVN shell dll, that would
have been detected a long time ago.

I really believe that you checked your own software carefully, but my
guess is that you forgot to do one check: stack overflow.

You see, when you use the shell dialogs, the shell also loads all shell
extension dlls - it's basically an explorer instance since the files
save/open dialogs are small explorer windows.
Loading so many shell extension dlls also means that each one of those
uses up some stack space.
My guess is that your application runs out of stack space, and that's
what's causing the heap corruption that's detected later.

If your app reserves a lot of stuff on the stack and/or you reduced the
stack size with the compiler option or you specified a small(er) value
when calling CreateThread, then you will eventually run into such
problems, whether you've got TSVN installed or not. Because you can not
control how many shell extension dlls or other dlls get loaded into your
process space.


> Among other modules, the Windows shell code also loads some SVN DLLs if
> it is installed every time the File Open dialog box is invoked. This is
> why we believe that the SVN code that is executed as part of the
> standard Windows File Open dialog box is responsible for the heap
> corruption. Unfortunately we were not able to identify a particular
> reason why the problem only showed up on this Japanese system. We have
> been using SVN for a long period of time, and we have never seen any
> crash problems. We assume that a specific file on the Japanese system
> causes a heap corruption (buffer overrun?) within the SVN code.
> Although we are unfortunately not able to tell you specific steps how to
> reproduce the problem, we thought that it would be worth reporting the
> issue to you. There is a possibility that Japanese characters in a file
> name or some other processing of Japanese characters cause a problem.
> Please feel free to contact me any time in case you need more
> information. Thank you.

TSVN is fully functional with any characters, even Japanese ones. There
also aren't any problems with Chinese or other non-English chars at all,
at least not that I'm aware of.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-12-04 21:31:17 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.