bzr 1.6.1/win32: hard crash because wrong libapr.dll is loaded

[Kuno Meyer]

Mark Hammond <mhammond <at> skippinet.com.au> writes:

> 
> > I wanted to report that the bzr-svn plugin from the 1.6.1 Windows
> > installer has some path problems: The libapr dlls aren't loaded from
> > the local Bazaar directory, but from the concurring SVN installation.
> > Unfortunately, the two DLL versions aren't binary compatible, leading
> > in my case to a NULL pointer access violation and an abrupt termination
> > of the bzr.exe process.
> 
> Strangely, I can't reproduce this.  In my subversion directory, I have a
> number of DLLs that are the same as bzr-svn uses, except for '-1' on the
> end.  Eg, in the bzr-svn directory you will find files libapr.dll,
> libapriconv.dll, libaprutil.dll, while by subversion directory has
> libapr-1.dll, libapriconv-1.dll and libaprutil-1.dll.  The subversion
> directory is on my PATH.
> 

That's correct. The DLLs deployed with SVN are loaded *in addition* to the DLLs
deployed with Bazaar. Therefore, the subject of my initial post is somewhat
misleading.

> You seem to have a similar layout - lookng at your trace:
> 
> > ModLoad: 01180000 01251000   C:\Program
> Files\Bazaar\plugins\svn\client.pyd
> 
> Here comes bzr-svn...
> 

[...]

> 
> So far, so good.  Note we have already loaded libaprutil.dll and
> libapriconv.dll 
> 
> But here things start going off the rails...
> 
> > ModLoad: 6e060000 6e066000   C:\Program
> Files\Subversion\iconv\windows-1252.so
> > ModLoad: 01e20000 01e29000   C:\Program
> Files\Subversion\bin\libapriconv-1.dll
> 
> We've started picking up stuff from subversion - and interestingly, we start
> loading the alternate '-1' versions of the libraries, and this is where we
> crash.
> 

[...]

> 
> Note that I see no reference to 'windows-1252.so', even though I do have an
> 'iconv' dir under subversion with this .so file and many others.  Maybe this
> is a clue?

This might be a clue indeed. I'm running a German version of Windows, as could
the reporter of bug 264733 (assumption based on its name). The messages from the
SVN command line interface are localized. The Win-1252 charset contains most of
the umlauts used in European languages
(<http://en.wikipedia.org/wiki/Windows-1252>).

Perhaps windows-1252.so is loaded dynamically in libapriconv.dll (which is the
only file containing the string "windows-1252"?

Perhaps we are just observing the consequence of not packaging windows-1252.so,
or of not forcing the SVN client library to run in english/neutral locale?

> 
> Alternatively, maybe a play with the 'depends' tool will offer a clue as to
> why your environment goes off searching for DLLs we aren't shipping?

I inspected several files (*.pyd, *.dll, *.so). No explicit reference to this
dll, but as stated above, it may be loaded dynamically from the libapriconv.dll.

Cheers
Kuno