Severity changed to major no documentation is a major loss of functionality and this takes loads of kde-windows developer time struggling with builds. I've got several mail respones from other developers to this bug but still no hard facts as to where it happens or a backtrace or so.

According to the libxml test suite, which is quite extensive, libxml2 seems to be ok with our patches.
testapi.exe output was:
libxml2: Total: 1162 functions, 291389 tests, 0 errors

First: 
I've got a reproducable crash: Paths may vary and not include enterprise5 but this is the source of kdelibs 4.6.0

r:\build\enterprise5\kdelibs-e5-20110117\work\kdelibs-4.6.0\doc\kioslave\mailto>cd r:\build\enterprise5\kdelibs-e5-20110
117\work\kdelibs-4.6.0\doc\kioslave\mailto && R:\build\enterprise5\kdelibs-e5-20110117\work\mingw4-Release-4.6.0\bin\mei
nproc4 --check --srcdir=R:/build/enterprise5/kdelibs-e5-20110117/work/mingw4-Release-4.6.0/kdoctools/ --cache R:/build/e
nterprise5/kdelibs-e5-20110117/work/mingw4-Release-4.6.0/doc/kioslave/mailto/index.cache.bz2 r:/build/enterprise5/kdelib
s-e5-20110117/work/kdelibs-4.6.0/doc/kioslave/mailto/index.docbook

Backtrace from mingw build without debug symbols: 

>	libxml2.dll!6f8c7690() 	
 	[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für libxml2.dll]	
 	libxml2.dll!6f915c2e() 	
 	libxml2.dll!6f91824e() 	
 	libxml2.dll!6f917d2b() 	
 	libxml2.dll!6f91b1de() 	
 	libxml2.dll!6f8eb747() 	
 	libxml2.dll!6f941801() 	
 	libxslt.dll!6fbdb77c() 	
 	libxslt.dll!6fbceafa() 	
 	libxslt.dll!6fbceafa() 	
 	libxslt.dll!6fbc2fb0() 	
 	libxml2.dll!6f8f7b53() 	
 	guard32.dll!1000223d() 	
 	meinproc4.exe!004013cb() 	
 	kernel32.dll!75293677() 	
 	ntdll.dll!77399d42() 	
 	ntdll.dll!77399d15()

After having a reproducable error case i could track the crashing line down with printf debugging to:
kdelibs/kdoctools/meinproc.cpp: QString output = transform(checkFilename , tss, params);

This is the only case where transform is called and that is only called if there is no arguemnt "htdig" (whatever that means) set.

Further debugging into transform ( kdelibs/kdoctools/xslt.cpp ) revealed that the crash occurs in line 178 xsltFreeStylesheet(style_sheet).

According to SaroEngels even if the Q_WS_WIN && SIMPLE_XSLT part is not in there it still crashes. I can verify this by checking the validity of the xsltprocExternalLoader return values.

Since style_sheet is a valid style_sheet the remaining "Bug Source" is libxml2 itself.

I've reverted all our code patches in libxml2 and it still crashes. I've set libxml2 to non threaded (which is not an option for kde but just for testing) and it still crashes.

Until a better solution is found the enterprise5 configuration of meinproc will include a patch delting that free. A memleak in a temporary process used during build is better then an altogether instable buildsystem.

SVN commit 1223913 by aheinecke:

Add a memory leak to meinproc but keep it from crashing.
Enable documentation build in kdelibs.

This is _not_ a fix but a hack to stop the accute problem. If someone understands why crashes occur in this free please do something about it!

CCBUG: 263828

 A             damn-you-meinproc.diff  
 M  +3 -2      kdelibs-e5-20110117.py  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1223913

meinproc in 4.6 branch and trunk crashes with msvc 2010 also with the mentioned patch. backtrace follows

I noticed that running kde 4.6 meinproc with 4.5 docbook did not crash. 4.5 uses docbook 4.1.2, 4.6 uses 4.2. 

BTW: There is an additional crash with msvc caused by the following stuff in meinproc_common.h

#if defined(_WIN32)
#include <windows.h>
#define setenv(x,y,z) SetEnvironmentVariable((LPCTSTR)x,(LPCTSTR)y)
#endif // _WIN32

here comes an msvc 2010 backtrace

 	verifier.dll!_VerifierStopMessage@40()  + 0x1f8 Bytes	
 	verifier.dll!_AVrfpDphReportCorruptedBlock@16()  + 0x239 Bytes	
 	verifier.dll!_AVrfpDphCheckNormalHeapBlock@16()  + 0x11a Bytes	
 	verifier.dll!_AVrfpDphNormalHeapFree@16()  + 0x22 Bytes	
 	verifier.dll!_AVrfDebugPageHeapFree@12()  + 0xe3 Bytes	
 	ntdll.dll!_RtlDebugFreeHeap@12()  + 0x2f Bytes	
 	ntdll.dll!@RtlpFreeHeap@16()  + 0x33f2e Bytes	
 	ntdll.dll!_RtlFreeHeap@12()  + 0x393c Bytes	
 	kernel32.dll!_HeapFree@12()  + 0x14 Bytes	
 	msvcr100.dll!free(void * pBlock)  Zeile 51	C
>	libxml2.dll!xmlFreeNode(_xmlNode * cur)  Zeile 3721 + 0x1c Bytes	C
 	libxml2.dll!xmlAddChild(_xmlNode * parent, _xmlNode * cur)  Zeile 3315	C
 	libxml2.dll!xmlSAX2Characters(void * ctx, const unsigned char * ch, int len)  Zeile 2525	C
 	libxml2.dll!xmlParseCharData(_xmlParserCtxt * ctxt, int cdata)  Zeile 4123 + 0x8 Bytes	C
 	libxml2.dll!xmlParseContent(_xmlParserCtxt * ctxt)  Zeile 9387 + 0x8 Bytes	C
 	libxml2.dll!xmlParseElement(_xmlParserCtxt * ctxt)  Zeile 9543	C
 	libxml2.dll!xmlParseContent(_xmlParserCtxt * ctxt)  Zeile 9371 + 0x6 Bytes	C
 	libxml2.dll!xmlParseElement(_xmlParserCtxt * ctxt)  Zeile 9543	C
 	libxml2.dll!xmlParseDocument(_xmlParserCtxt * ctxt)  Zeile 10211	C
 	libxslt.dll!52e69cf8() 	
 	[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für libxslt.dll]	
 	libxslt.dll!52e684b2() 	
 	libxslt.dll!52e5510e() 	
 	libxslt.dll!52e55533() 	
 	libxslt.dll!52e55aa1() 	
 	libxslt.dll!52e68308() 	
 	libxslt.dll!52e54fb4() 	
 	libxslt.dll!52e55533() 	
 	libxslt.dll!52e55aa1() 	
 	libxslt.dll!52e68308() 	
 	libxslt.dll!52e54fb4() 	
 	libxslt.dll!52e55533() 	
 	libxslt.dll!52e55aa1() 	
 	libxslt.dll!52e68308() 	
 	libxslt.dll!52e54fb4() 	
 	libxslt.dll!52e55533() 	
 	libxslt.dll!52e55aa1() 	
 	libxslt.dll!52e68308() 	
 	libxslt.dll!52e54fb4() 	
 	libxslt.dll!52e55533() 	
 	libxslt.dll!52e55aa1() 	
 	libxslt.dll!52e55b32() 	
 	libxslt.dll!52e55be9() 	
 	meinproc4.exe!transform(const QString & pat, const QString & tss, const QVector<char const *> & params)  Zeile 146 + 0x2b Bytes	C++
 	meinproc4.exe!main(int argc, char * * argv)  Zeile 240 + 0x19 Bytes	C++
 	meinproc4.exe!__tmainCRTStartup()  Zeile 555 + 0x17 Bytes	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 Bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 Bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b Bytes	


===========================================================
VERIFIER STOP 00000010: pid 0x21D4: corrupted start stamp 

	03C91000 : Heap handle
	05674CB0 : Heap block
	72617600 : Block size
	636E6900 : Corrupted stamp
===========================================================
This verifier stop is not continuable. Process will be terminated 
when you use the `go' debugger command.
===========================================================

After digging into libxml and the windows patches for a few hours I recognized three issues for msvc 2010: 

1. Some of the source patches related to tree.c which has been required 3 years ago does not fit anymore with kde 4.6 and results into crashing libxml2.
Removing this patch do not have any known negative side effect with kde 4.6 (kde 4.5 not tested yet)

2. The setenv problem reported in 2011-03-24 21:50:22

3. The problems covered by the damn-you-meinproc.diff is caused by an access to an already free'd node in __xmlRaiseError() and xmlCtxtDumpNode(). The node pointer and/or some members are set to 0xdddddddd, which indicates the free'd situation - see http://www.nobugs.org/developer/win32/debug_crt_heap.html for more informations. No idea yet, where this happens. I found a workaround by checking the node pointer against the value 0xdddddddd, but this is a msvc only solution. 

diff -Nru libxml2-2.7.8.orig/error.c libxml2-2.7.8/error.c
--- libxml2-2.7.8.orig/error.c	2010-10-12 08:25:32.000000000 +0200
+++ libxml2-2.7.8/error.c	2011-03-26 19:12:45.703738300 +0100
@@ -509,7 +509,7 @@
             }
         }
         to = &ctxt->lastError;
-    } else if ((node != NULL) && (file == NULL)) {
+    } else if ((node != NULL && node->doc != 0xdddddddd) && (file == NULL)) {
 	int i;
 
 	if ((node->doc != NULL) && (node->doc->URL != NULL)) {

diff -Nru libxml2-2.7.8.orig/debugXML.c libxml2-2.7.8/debugXML.c
--- libxml2-2.7.8.orig/debugXML.c	2010-11-04 10:44:21.000000000 +0100
+++ libxml2-2.7.8/debugXML.c	2011-03-26 19:53:11.856437700 +0100
@@ -1067,6 +1069,13 @@
         }
         return;
     }
+    if (node == (xmlNodePtr*)0xdddddddd) {
+        if (!ctxt->check) {
+            xmlCtxtDumpSpaces(ctxt);
+            fprintf(ctxt->output, "node is freed\n");
+        }
+        return;
+    }
     xmlCtxtDumpOneNode(ctxt, node);
     if ((node->type != XML_NAMESPACE_DECL) && 
         (node->children != NULL) && (node->type != XML_ENTITY_REF_NODE)) {
@@ -1087,7 +1096,7 @@
 static void
 xmlCtxtDumpNodeList(xmlDebugCtxtPtr ctxt, xmlNodePtr node)
 {
-    while (node != NULL) {
+    while (node != NULL && node != 0xdddddddd) {
         xmlCtxtDumpNode(ctxt, node);
         node = node->next;
     }
diff -Nru libxml2-2.7.8.orig/error.c libxml2-2.7.8/error.c
--- libxml2-2.7.8.orig/error.c	2010-10-12 08:25:32.000000000 +0200
+++ libxml2-2.7.8/error.c	2011-03-26 19:12:45.703738300 +0100
@@ -509,7 +509,7 @@
             }
         }
         to = &ctxt->lastError;
-    } else if ((node != NULL) && (file == NULL)) {
+    } else if ((node != NULL && node->doc != 0xdddddddd) && (file == NULL)) {
 	int i;
 
 	if ((node->doc != NULL) && (node->doc->URL != NULL)) {

... so far

I can confirm Ralfs backtrace. However not with an own backtrace - I do not yet know how to produce that on Windows, relwithdebug. But I inserted debug output and found the problem in xmlFreeNode at DICT_FREE(cur->content)

this always happens while parsing docbook/xsl-stylesheets-1.75.2/html/glossary.xsl, while meinproc4ing calligra/calligra/index.docbook

BUT if I compile libxml2 with DEBUG_MEMORY and DEBUG_MEMORY_LOCATION defined, meinproc4.exe finishes without any error!

and on Linux valgrind finds nothing.

Ralf, if you enable DEBUG_MEMORY and DEBUG_MEMORY_LOCATION, does your heap checker still find a problem? If not, what about Andre mentioning win-iconv? Is it possible to revert the switch to win-iconv just for testing?

actually DEBUG_MEMORY and friends do find a problem but they hide it just like Ralfs patch and continue so I missed it in the output

I have a minimal file which makes meinproc4 crash:

<?xml version='1.0'?>
<!DOCTYPE xsl:stylesheet [
]>

this causes a syntax error on linux but on windows it still crashes in the same place. At the crash place DEBUG_MEMORY finds a tag error: the memory block to be freed is not marked with the correct tag (DEBUG_MEMORY adds a header with this tag and more debug data to every malloced block) so maybe something writes thru a wrong pointer or out of array bounds. Still valgrind on linux finds nothing. 

Continuing later today... maybe I should regularly scan all memory blocks for correct tags so I can find the place where it gets corrupted but that will take a lot of time even with that minimal test file. The debug output is about 10GB

Any idea what could be different for linux and windows?

I think I found a real bug in libxml2:
http://mail.gnome.org/archives/xml/2011-April/msg00006.html

but I do not yet know why this does not happen on Linux, and I reduced all those xsl files to a very short test case (which still segfaults in the same place of course). I will have to test again with the full xsl files

Since our current release 4.8.0 contains all documentation and meinproc doesn't crash anymore, I'll just close this bug. Thanks to whoever fixed it.

I guess its fixed since we don't build libxml2 with multithread support anymore