I found part of the problem.
I had been building everything with gcc-4.0.3 -O1 -g. It turns out that
this option pairing can generate bad code. Some local variables get
optimized to registers, but then the stack version (which is never updated)
gets passed to function calls. It took a good bit of assembly level
debugging to figure this out.
Rebuilding everything with just -g fixed most of the core dumps. What is
left is some kind of corruption of the default memory pool that shows up at
the final pool destruction (both neon and serf).
-Dan C
P.S. In case you're wondering why use -g -O1, it enables warnings about
unused variables without making debugging weird (due to code re-ordering).
I've used this for years, but 4.0.3 seems to have some problems with it.
On 6/18/07, Dan Christian <dchristian@google.com> wrote:
>
> On 6/18/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
>
> > mstone is using threads, right? So, there could be some thread-safety
> > issues here...
>
>
> There are core dumps from runs where there is only 1 thread doing
> subversion work (plus a thread collecting performance results and the master
> thread just waits for the others). Look for "-N 1" in the command line for
> these runs (I count 9 of them). Also, I still get failures if I build
> mstone without threading.
>
> It does fail faster when there are multiple worker threads. Each thread
> is completely independent inside mstone (separate WC, memory pools, etc).
> However, I don't know if the subversion libraries are sharing things. I
> found out that openssl does this, but serf should be setting up the proper
> openssl locking now.
>
> I'll see about updating. The new neon/serf switching will require some
> work before I can do comparison runs again.
>
> -Dan C
>
>
Received on Mon Jun 25 19:45:35 2007