on amd64. It seems that xmlGenericErrorContext is (*__xmlGenericErrorContext()) and seems to evaluate differently in the three calls that are made here. The first two return the same value but the third returns a different value. This causes vfprintf to get NULL as the first argument even though the code appears to guard against that.
and it seems that IS_MAIN_THREAD evaluates to zero on all three cases. xmlGetGlobalState(), however, returns first 0x7fffe4019170 and then 0x7fffe4019540. Both have sane data but of course only the first one is updated to refer to stderr, the second one has xmlGenericErrorContext set to zero.
xmlGetGlobalState looks very complicated, I can't immediately see why it would return different value for the same thread during the same function call.
I looked at the disassembly of
void XMLCDECL orDefaultFunc( void *ctx ATTRIBUTE_UNUSED, const char *msg, ...) {
xmlGenericErr
va_list args;
if (xmlGenericErro rContext == NULL)
xmlGenericEr rorContext = (void *) stderr;
va_ start(args, msg); (FILE *)xmlGenericErr orContext, msg, args);
vfprintf(
va_end(args);
}
on amd64. It seems that xmlGenericError Context is (*__xmlGenericE rrorContext( )) and seems to evaluate differently in the three calls that are made here. The first two return the same value but the third returns a different value. This causes vfprintf to get NULL as the first argument even though the code appears to guard against that.
The implementation has
void * * orContext( void) { orContext) ; tate()- >xmlGenericErro rContext) ;
__xmlGenericErr
if (IS_MAIN_THREAD)
return (&xmlGenericErr
else
return (&xmlGetGlobalS
}
and it seems that IS_MAIN_THREAD evaluates to zero on all three cases. xmlGetGlobalSta te(), however, returns first 0x7fffe4019170 and then 0x7fffe4019540. Both have sane data but of course only the first one is updated to refer to stderr, the second one has xmlGenericError Context set to zero.
xmlGetGlobalState looks very complicated, I can't immediately see why it would return different value for the same thread during the same function call.
Anyways, if I apply
diff -u libxml2- 2.7.8.dfsg/ debian/ changelog libxml2- 2.7.8.dfsg/ debian/ changelog 2.7.8.dfsg/ debian/ changelog 2.7.8.dfsg/ debian/ changelog dfsg-2lindi0) unstable; urgency=low /bugs.launchpad .net/ubuntu/ +source/ foxtrotgps/ +bug/787953
--- libxml2-
+++ libxml2-
@@ -1,3 +1,9 @@
+libxml2 (2.7.8.
+
+ * Try to workaround https:/
+
+ -- Timo Lindfors <email address hidden> Wed, 01 Jun 2011 00:55:10 +0300
+
libxml2 (2.7.8.dfsg-2) unstable; urgency=low
* xpath.c: Fix a double-freeing error in XPath processing code. 2.7.8.dfsg. orig/error. c 2.7.8.dfsg/ error.c rDefaultFunc( void *ctx ATTRIBUTE_UNUSED, const char *msg, ...) { Context;
only in patch2:
unchanged:
--- libxml2-
+++ libxml2-
@@ -70,12 +70,13 @@
void XMLCDECL
xmlGenericErro
va_list args;
+ void *errorContext = xmlGenericError
- if (xmlGenericErro rContext == NULL) Context = (void *) stderr;
- xmlGenericError
+ if (errorContext == NULL)
+ errorContext = (void *) stderr;
va_start(args, msg); orContext, msg, args);
- vfprintf((FILE *)xmlGenericErr
+ vfprintf((FILE *)errorContext, msg, args);
va_end(args);
}
to libxml2 I do not see the crash anymore.
I doubt the bug is in libxml2 itself but this information might help in any case. I suspect some threading bug in foxtrotgps.