I took some time to get Python bindings compiling and such on Win2k
tonight (for the third time, because every time I get them working on
one machine, I forget to put the diff somewhere I can reach from other
machines).
Anyway, was doing some testing, and I ran into an interesting problem
I'd not hit before.
First, I'll explain my setup.
Of course, Subversion itself builds in the most brain-dead fashion on
Windows. Oh, no, wait, that's right -- it *doesn't* build on
Windows. I should mention that I have, as local mods, the reversion
of gstein's DSP-dispose-all commit. So, that in place, we're back to
brain-dead compilation of a bunch of .libs and then some massing svn,
svnadmin, and svnlook binaries.
I have swigutil_py.lib as well.
And finally, I have a bunch of DLLs -- _client, _fs, _wc, etc.
Things work really well until Subversion's make_error_internal()
function gets called. I was quite puzzled, at first. Now, note that
make_error_internal() is probably the only place in Subversion's
librarized code where a new subpool is created from APR's global
uberparent pool. I was able to debug the crash, and found that when
make_error_internal() goes to make this subpool, the global_pool is
NULL.
What?!
Oh.
Duh (or so I'm thinking).
Yeah. I called util.apr_initialize() at the beginning of my Python
app, which initializes the APR global_pool. But that init is only
good for the current DLL's statically linked APR instantiation. In
other words, the other Python modules also have copies of APR compiled
into them, but those copies haven't been init'ed.
At least, that's what thinking at 4:00am has yielded. Am I just
completely off-base here?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 3 11:10:20 2003