Re: [xml] xmlSaveFormatFileEnc - xml file with binary zeros

On Fri, Jul 31, 2009 at 10:01:24AM +0200, Martin Trappel wrote:
Hi all.

At a customer site we had the case that one configuration file we always  
write from our app was 789KB of binary zeros (0x00 / '\0').

The call we use to save the file is:
  WCharToUTF8(m_csXMLFile).c_str(), // generate UTF8 name from CString

I thought maybe someone has a creative idea what could have happened to  
our program state to create such a file through this call. (Of course  
the whole thing isn't reproducible :/ )

I have seen that saving the data ends up in xmlio.c:xmlFileWrite which  
calls fwrite(&buffer[0], len, 1, (FILE *) context)
The call comes from xmlio.c:xmlOutputBufferFlush where the writecallback  
is invoked:
ret = out->writecallback(out->context, (const char *)out->conv->content,  

So for libxml to actually generate such a file we'd need a valid  
xmlBufferPtr(out->conv) with a sufficiently large buffer that is zero'd 
Not much chance for that, or??

Thx in adv for any ideas and pointers, libxml related or not!

in general my bet would be a bug in the conversion routines, it would be
useful to know what ended being used. On some systems it's dynamically
shared libraries which implement iconv and things can become really hard
to trace from there. But in this case, XML_ENCODING_UTF8, means the
internal tree encoding of libxml2, so encoding is a no-op and it looks
like the serialization buffer got overriden by zeroes. Very weird,
I have no idea how this could happen, if multithreaded a bug elsewhere
might override part of the buffer but getting only zeroes and not
crashing due to other data being tampered sounds unlikely. Last
possibility is a bug in the I/O system...


Daniel Veillard      | libxml Gnome XML XSLT toolkit
daniel veillard com  | Rpmfind RPM search engine | virtualization library

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]