Rob, I've tried building my app on both debug and release, and the same thing happens. You're saying there may be something wrong with my build environment? I'm not entirely convinced of that but I won't rule it out as a possibility.
I'm running Visual C++ Express 2005 (which is basically VC8, if you actually paid for a copy) Microsoft Windows 2003 Server R2 Platform SDK It's all basically the latest and greatest non-beta stuff that Microsoft has out right now. libxml2-2.6.30 (binary) as gotten from: http://www.zlatkovic.com/libxml.en.html Why would I run into heap corruption issues unless there's something blatantly wrong with xmlDocDump. My understanding of HEAP vs STACK memory is that local variables come from the stack and global variables along with anything malloc() comes off of the heap. Heap memory is essentially limited only by the amount of physical RAM and virtual memory in your machine whereas your call stack is generally limited to 1Mbit per thread by default on Windows. If anything I would say that there's a stack corruption issue here, not a heap corruption issue, and that could easily be caused somewhere else in the code (my code) without me noticing. The default stack size in most Linux distributions is unlimited or some very high number so I could easily see how I may have missed a stack issue. Issues with the heap tend to be more visible (in the form of crashes) and obvious (dereferencing null or uninitialized pointers, reading/writing out-of-bounds, etc) That's a semantic point at any rate. It's beginning to look like I'm going to need to fetch the source and compile it myself so that I can give you more useful debugging information :( xmlDocDump is the cleaner approach in this case than xmlSaveFile. The reason being is that the xmlSaveFile documentation clearly states that compression is used by default if it is compiled in to the library and this is a bad thing for general deployment. -Daniel On 9/13/07, Rob Richards <[EMAIL PROTECTED]> wrote: > > Daniel Corbe wrote: > > Sorry but I must reject this notion. You're trying to say that it's > > broken the way I'm using it, but just on Windows? Because like I said > > on Linux it runs fine. > I am saying that it was either that or you are mixing release and debug > versions and probably running into a problem on the HEAP somewhere. > Just to make sure this wasn't something new, I did try your example code > and it worked flawlessly (hardcoding path names of course and using "wb" > for mode as I have no idea what you defined OPEN_MODE_OVERWRITE as). > > I used both a debug version of libxml2 and my calling executable. They > were both built with VS 2005 and I'll test again later building the > executeable against a VC6 version of libxml2. > > > > > I'm trying to do something EXTREMELY simple here. See below. In my > > experience if xmlReadFile fails I get a bunch of things to stderr > > about why and my program then exists. > > > > And I have also verified with a debugger that mtp3 is indeed a valid > > pointer. So if mtp3 is a valid and parsed and my FILE*xml is also a > > valid pointer, xmlDocDump would have no reason to fail. > > > > I have attached some screenshots highlighting the failure. > > > > /* Begin code snippet */ > > xmlDocPtr mtp3; > > FILE *xml; > > > > mtp3 = xmlReadFile(config->MTP3filename, NULL, 0); > > xml = fopen(config->MTP3filename, FOPEN_MODE_OVERWRITE); > > if (!xml || ferror(xml)) > > { > > > > outputf("ERROR WRITING MTP3 XML File: %s\n", strerror(errno)); > > } > > else > > { > > xmlDocDump(xml, mtp3); > > fclose(xml); > > } > Try a debug version of libxml2 and if it crashes then, you should be > able to find out why at least because I cannot reproduce your crash. > > Rob >
_______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
