Re: [xml] 2.4.27 thread problems

["William M. Brack" <wbrack mmm com hk>]

[snip]
> > It seems to be caused
> > by the changing of the line
> >
> >    initxmlDefaultSAXHandler(sax, xmlGetWarningsDefaultValue);
> >
> > to become
> >
> >    memcpy(sax, &xmlDefaultSAXHandler, sizeof(xmlSAXHandler));
> >
> >   Well, stupid me, I can't see any reason why the change
> > shouldn't
> > work (or, more precisely, why this should not be thread-safe).

> I can understand it being not thread safe because the memcpy does
> not take an exclusive lock before trying to access this global
> variable. If another thread modifies it at the same time anything
> can happen.

I understand the principle of requiring locks, but in this
particular case (program testThreads) I fail to see where any
"modification" is being made to the structure.  The structure
xmlDefaultSAXHandler is preset within global.c (with 'initialized'
set to 0), then when the first thread does its parsing it is re-set
(by xmlDefaultSAXHandlerInit called from xmlInitParserCtxt) and
'initialized' is set to 1.  After that, the structure should no
longer be modified (but I'm pretty well convinced that it is, and
the modification is causing the crash!  It's just that I can't,
despite a couple of hours of searching and debugging, find where it
happens).

I fully agree with your comments on a better change being required
for the "general case".  My concern is that I need to prove to
myself that the crash is fully explained.  I always dread falling
into the trap of "It was raining; my program crashed; therefore, the
crash must be because of the rain" :-)

Regards,
Bill