Fixed
Created: Dec 20, 2016
Updated: Sep 8, 2018
Resolved Date: Jan 17, 2017
Found In Version: 7.0
Fix Version: 7.0.0.23
Severity: Severe
Applicable for: Wind River Linux 7
Component/s: Userspace
There is a bug in libxml2 library, on the board, we got the following backtrace:
/************************************************************************/
Stack infomation when exception:
libxml2.so.2(+0xfb676f0) [0x481556f0]
libxml2.so.2(+0xfb6f400) [0x4815d400]
libxml2.so.2(xmlParseChunk+0x33c) [0x4815ea9c]
libnca.so(NCA_UTL_AccInputRpc+0x288) [0xb64a298]
libnca.so(NCA_UTL_CreateParserCtxt+0x214) [0xb64a654]
libnca.so(NCA_SHL_ProcCamlTransMsg+0x7a0) [0xb77ac80]
libnca.so(NCA_MAIN_MapCamlMsg+0x1f0) [0xb6bdcd0]
libnca.so(NCA_CAML_ProcCamlMsg+0x17c) [0xb69689c]
libnca.so(NCA_MsgProc+0x29c) [0xb78585c]
libdefault.so(RTF_MsgProcessCbk+0x21c) [0xf85ed8c]
libdefault.so(rtfScmMessageSchedule+0x3d8) [0xf85d098]
libdefault.so(rtfScmCompScheKernelEntryFifo+0x11c) [0xf85dccc]
libdefault.so(rtfScmCompSchTaskEntry+0x1e8) [0xf859518]
libdefault.so(rtfScmCompScheDefaultEntry+0x110) [0xf859630]
libdefault.so(rtfScmTaskDeployDefaultCompEntry+0x24) [0xf85bf64]
libdefault.so(tskAllTaskEntry+0x17c) [0xf768c7c]
libpthread.so.0(+0xff97fa0) [0x48008fa0]
libc.so.6(clone+0x84) [0xfdaa060]
Reg: msr, Val = 0x0002d002 : Reg: orig_gpr3, Val = 0x00000000 :
Reg: ctr, Val = 0xc037c3e0 : Reg: link, Val = 0x481556f0 :
Reg: xer, Val = 0x20000000 : Reg: ccr, Val = 0x28882482 :
Reg: mq, Val = 0x00000000 : Reg: trap, Val = 0x00000300 :
Reg: dar, Val = 0x00000000 : Reg: dsisr, Val = 0x00000000 :
Reg: result, Val = 0x00000000 :
/************************************************************************/
after disassmber the libxml2 library based on the backtrace, located the problem in xmlParseStartTag2
xmlParseChunk will call xmlParseTryOrFinish, and xmlParseTryOrFinish will call xmlParseStartTag2, in xmlParseStartTag2, xmlDictLookup will be called, some times, xmlDictLookup will return with NULL,:
/*********************************************************/
if ((attname == ctxt->str_xmlns) && (aprefix == NULL)) {
const xmlChar *URL = xmlDictLookup(ctxt->dict, attvalue, len);
xmlURIPtr uri;
if (*URL != 0) {
uri = xmlParseURI((const char *) URL);
if (uri == NULL) {
xmlWarningMsg(ctxt, XML_WAR_NS_URI,
"xmlns: %s not a valid URI\n",
URL, NULL);
} else {
if (uri->scheme == NULL) {
xmlWarningMsg(ctxt, XML_WAR_NS_URI_RELATIVE,
"xmlns: URI %s is not absolute\n",
URL, NULL);
}
xmlFreeURI(uri);
}
}
/*********************************************************/
But there is no treatment when URL is null pointer, when try to access this null pointer, there will be the above error backtrace.
This issue can be reproduced on customer side.
