Re: [xml] xmlNewTextWriterFilename Win32 Problem

[Coleman Brumley <coleman brumley comcast net>]

OK, I've re-written my code so that the two file name string nonsense 
from below is non-existent.  I'm no longer convinced my code is the 
culprit here.

So, I have function, XMLWriteData(char *v) where v is a path and file 
name as returned from GetOpenFileName.  I've verified that it's not a 
synchronization issue and XMLReadData (a thread) is working correctly.  
Still, the code is crashing when calling xmlNewTextWriterFilename.  
xmlNewTextWriterFilename doesn't return, it just crashes in NTDLL.dll 
somewhere (0x7C918FEA).  Based on a Google search for "7C918FEA 
libxml2", this seems to have happened to the Python folks, too. 

This seems to exhibit the same behvior as 
http://www.myday.com.tw/guest/product.php?http://bugzilla.gnome.org/buglist.cgi?product=libxml2.  
I'm more than happy to help someone correct the problem.  Again, this 
only happened when making my XMLReadData function into a thread, so 
maybe that function isn't cleaning up correctly or something. Maybe a 
critical section isn't being deleted?  Note that 7C918FEA is in 
RtlpWaitForCriticalSection. 

- Coleman

Coleman Brumley wrote:

> Bjorn,
>
> Yes, of course you're correct and that's a flaw in my thread design.  
> Thank you for pointing that out.  I had even tried an attempt at 
> putting fname on the heap and that made things worse.
> So, likely what I'll do is:
> populate fname
> _beginthreadex(...,fname,...)
> waitforsingleobject(...) --> the object will be set in the XMLReadData 
> thread after the contents of fname are copied locally via memmove
>
> However, that's a flaw in XMLReadData which doesn't have a problem.  
> What threw me is that XMLWriteData is *not* multi threaded and only 
> started exhibiting this behavior when I made XMLReadData a thread. If 
> both functions remain single threaded, there is no problem.  That 
> doesn't seem to me to be a synchronization issue and I don't see how 
> improving the design of XMLReadData would have any effect.
> I will double check my project settings and see if I'm linked to the 
> wrong multi-thread library or something.
> - Coleman
>
> Bjorn Reese wrote:
>
> > Coleman Brumley wrote:
> >
> > > I have a strange problem with xmlNewTextWriterFilename on Win32.
> >
> >
> >
> > I believe that your problem is related to multi-threading, not libxml
> > per se.
> >
> > > I have two file name strings:
> > > char outname[MAX_PATH]={(char)0};
> > > static char fname[MAX_PATH]={(char)0};
> >
> >
> >
> > Are they global or local variables? The static keyword has two different
> > meanings for these two cases.
> >
> > > outname gets passed to a function XMLWriteData(const char *file) 
> > > which in turn calls xmlNewTextWriterFilename(file,0);.  As long as 
> > > the fname variable (which gets passed to XMLReadData via the 
> > > CreateThread function) is static, xmlNewTextWriterFilename crashes 
> > > and generates an access violoation in NTDLL.
> > > As soon as I change the declarations to:
> > > char outname[MAX_PATH]={(char)0};
> > > /*static*/ char fname[MAX_PATH]={(char)0};
> > >
> > > xmlNewTextWriteFilename works fine.
> >
> >
> >
> > I am going to assume that fname is a local variable. You can think of
> > a static local variable as a global variable that cannot be seen from
> > outside the function where it is defined.
> >
> > The point is that only one buffer exist in memory for fname. If you
> > change the contents of fname, it will affect all threads. This can lead
> > to strange behavior. So given the above information, my guess is that
> > the observed behavior occurs because you access a shared resource
> > (fname) from multiple threads without any synchronization.
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml