From jasmine05@example.org Fri Apr 01 15:54:46 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 90422 invoked from network); 1 Apr 2011 15:54:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Apr 2011 15:54:46 -0000 Received: (qmail 75236 invoked by uid 500); 1 Apr 2011 15:54:46 -0000 Delivered-To: jasmine05@example.org Received: (qmail 75158 invoked by uid 500); 1 Apr 2011 15:54:46 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 75057 invoked by uid 99); 1 Apr 2011 15:54:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Apr 2011 15:54:46 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Apr 2011 15:54:43 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id B7BE48E015 for <jasmine05@example.org>; Fri, 1 Apr 2011 15:54:05 +0000 (UTC) Date: Fri, 1 Apr 2011 15:54:05 +0000 (UTC) From: "Mangesh Narulkar (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> Subject: [jira] [Created] (XERCESC-1960) Application crashing in the XMLString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4transcode MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org Application crashing in the XMLString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4transcode ------------------------------------------------- Key: XERCESC-1960 URL: https://issues.apache.org/jira/browse/XERCESC-1960 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 1.6.0 Environment: Uname -a SunOS MUMCTSarc01 5.10 Generic_141444-09 sun4v sparc SUNW,T5240 Showrev output Hostname: MUMCTSarc01 Hostid: 84f8e614 Release: 5.10 Kernel architecture: sun4v Application architecture: sparc Hardware provider: Sun_Microsystems Domain: Kernel version: SunOS 5.10 Generic_141444-09 Reporter: Mangesh Narulkar hi We are using xerces 1.6 in our application. Our appilication crashes frequently in XMLString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4transcode function. Following is the stack trace of the core ff0d7264 _smalloc (8, 0, d9200, ff0d73f4, fffffff9, ff1b929c) + 98 ff0d72d0 malloc (7, 1, d914c, ff142f40, ff1b03d8, ff1ba5a0) + 4c fe7570a8 __1c2n6FI_pv_ (7, ffbfb330, 30, 14ea8, fe76bf28, 6) + 2c fe897aa4 __1cSIconvLCPTranscoderJtranscode6MkpkH_pc_ (c961c0, 90858, fe9d8c0c, c961c0, fe992f7c, fe8979dc) + c8 fed2d564 __1cKXMLHandlerMstartElement6MkpkHkp1k4rknKAttributes__v_ (613e8, 8f5c8, 32a68, 32a40, 92ec4, 8f5c8) + 2e0c fe8bcee0 __1cRSAX2XMLReaderImplMstartElement6MrknOXMLElementDecl_kIkpkHrknLRefVectorOf4nHXMLAttr___4kb9C_v_ (92eb0, c93d18, 1, 5ce50, 92a18, 2) + 25c fe90097c __1cKXMLScannerOscanStartTagNS6Mrb_b_ (0, c93d18, fe8be500, 1, 2, fe98fd78) + 1264 fe8fd828 __1cKXMLScannerLscanContent6Mkb_b_ (92fb0, 1, 1, fe9d8f74, fe9d8f9c, fe9c88b1) + 180 fe8fb3a0 __1cKXMLScannerMscanDocument6MrknLInputSource_kb_v_ (92fb0, 92eb4, fe9c38e4, fe8be514, 92eb4, 0) + 80 fe8fb1c4 __1cKXMLScannerMscanDocument6MkpkHkb_v_ (92fb0, 65460, 0, c961c0, fe992f7c, fe897bf0) + 84 fe8fb2f0 __1cKXMLScannerMscanDocument6Mkpkckb_v_ (92fb0, fead0ea0, 0, e03b8e3f, c1800, 1dc71f8) + 28 fe8bc528 __1cRSAX2XMLReaderImplFparse6Mkpkc_v_ (92eb0, fead0ea0, fed38098, fed380a5, ffbfca9c, ff142f40) + 7c fed292f8 ParseXML (fead0ea0, 1, fea4e2db, fea4e2e9, ffbfcef4, 1) + f8 fea300cc PMStart (1, 0, 0, fea78924, ffbfd180, ff041170) + f3c fea1f544 ProcessFile (ff041170, ffbfd894, 3, 80808080, ff00, 80808080) + 5fc fea200f4 XMLInlibMain (ff040000, ffbfdc80, ffbffc24, ffbffc44, 49e0, 274bc) + 7d4 00014698 main (ffbfdbf8, ffbffc24 Please let us know the resolution for the issue in version 1.6 itself ,as we cannot upgrade to higher versions of xerces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Fri Apr 01 16:04:50 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 34068 invoked from network); 1 Apr 2011 16:04:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Apr 2011 16:04:49 -0000 Received: (qmail 99580 invoked by uid 500); 1 Apr 2011 16:04:49 -0000 Delivered-To: jasmine05@example.org Received: (qmail 99550 invoked by uid 500); 1 Apr 2011 16:04:49 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 99543 invoked by uid 99); 1 Apr 2011 16:04:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Apr 2011 16:04:49 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Apr 2011 16:04:47 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id 6ADCA8E321 for <jasmine05@example.org>; Fri, 1 Apr 2011 16:04:09 +0000 (UTC) Date: Fri, 1 Apr 2011 16:04:09 +0000 (UTC) From: "Mangesh Narulkar (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> In-Reply-To: <jasmine05@example.org> Subject: [jira] [Updated] (XERCESC-1960) Application crashing in the XMLString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4transcode MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/XERCESC-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mangesh Narulkar updated XERCESC-1960: -------------------------------------- Priority: Blocker (was: Major) > Application crashing in the XMLString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4transcode > ------------------------------------------------- > > Key: XERCESC-1960 > URL: https://issues.apache.org/jira/browse/XERCESC-1960 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous > Affects Versions: 1.6.0 > Environment: Uname -a > SunOS MUMCTSarc01 5.10 Generic_141444-09 sun4v sparc SUNW,T5240 > Showrev output > Hostname: MUMCTSarc01 > Hostid: 84f8e614 > Release: 5.10 > Kernel architecture: sun4v > Application architecture: sparc > Hardware provider: Sun_Microsystems > Domain: > Kernel version: SunOS 5.10 Generic_141444-09 > Reporter: Mangesh Narulkar > Priority: Blocker > Labels: function, transcode > > hi > We are using xerces 1.6 in our application. Our appilication crashes frequently in XMLString888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4transcode function. > Following is the stack trace of the core > ff0d7264 _smalloc (8, 0, d9200, ff0d73f4, fffffff9, ff1b929c) + 98 > ff0d72d0 malloc (7, 1, d914c, ff142f40, ff1b03d8, ff1ba5a0) + 4c > fe7570a8 __1c2n6FI_pv_ (7, ffbfb330, 30, 14ea8, fe76bf28, 6) + 2c > fe897aa4 __1cSIconvLCPTranscoderJtranscode6MkpkH_pc_ (c961c0, 90858, fe9d8c0c, c961c0, fe992f7c, fe8979dc) + c8 > fed2d564 __1cKXMLHandlerMstartElement6MkpkHkp1k4rknKAttributes__v_ (613e8, 8f5c8, 32a68, 32a40, 92ec4, 8f5c8) + 2e0c > fe8bcee0 __1cRSAX2XMLReaderImplMstartElement6MrknOXMLElementDecl_kIkpkHrknLRefVectorOf4nHXMLAttr___4kb9C_v_ (92eb0, c93d18, 1, 5ce50, 92a18, 2) + 25c > fe90097c __1cKXMLScannerOscanStartTagNS6Mrb_b_ (0, c93d18, fe8be500, 1, 2, fe98fd78) + 1264 > fe8fd828 __1cKXMLScannerLscanContent6Mkb_b_ (92fb0, 1, 1, fe9d8f74, fe9d8f9c, fe9c88b1) + 180 > fe8fb3a0 __1cKXMLScannerMscanDocument6MrknLInputSource_kb_v_ (92fb0, 92eb4, fe9c38e4, fe8be514, 92eb4, 0) + 80 > fe8fb1c4 __1cKXMLScannerMscanDocument6MkpkHkb_v_ (92fb0, 65460, 0, c961c0, fe992f7c, fe897bf0) + 84 > fe8fb2f0 __1cKXMLScannerMscanDocument6Mkpkckb_v_ (92fb0, fead0ea0, 0, e03b8e3f, c1800, 1dc71f8) + 28 > fe8bc528 __1cRSAX2XMLReaderImplFparse6Mkpkc_v_ (92eb0, fead0ea0, fed38098, fed380a5, ffbfca9c, ff142f40) + 7c > fed292f8 ParseXML (fead0ea0, 1, fea4e2db, fea4e2e9, ffbfcef4, 1) + f8 > fea300cc PMStart (1, 0, 0, fea78924, ffbfd180, ff041170) + f3c > fea1f544 ProcessFile (ff041170, ffbfd894, 3, 80808080, ff00, 80808080) + 5fc > fea200f4 XMLInlibMain (ff040000, ffbfdc80, ffbffc24, ffbffc44, 49e0, 274bc) + 7d4 > 00014698 main (ffbfdbf8, ffbffc24 > Please let us know the resolution for the issue in version 1.6 itself ,as we cannot upgrade to higher versions of xerces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Tue Apr 05 16:33:44 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 14463 invoked from network); 5 Apr 2011 16:33:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Apr 2011 16:33:44 -0000 Received: (qmail 85776 invoked by uid 500); 5 Apr 2011 16:33:44 -0000 Delivered-To: jasmine05@example.org Received: (qmail 85743 invoked by uid 500); 5 Apr 2011 16:33:44 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 85736 invoked by uid 99); 5 Apr 2011 16:33:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Apr 2011 16:33:44 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Apr 2011 16:33:43 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id 3F84393FE9 for <jasmine05@example.org>; Tue, 5 Apr 2011 16:33:06 +0000 (UTC) Date: Tue, 5 Apr 2011 16:33:06 +0000 (UTC) From: "Peter Burns (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> Subject: [jira] [Created] (XERCESC-1961) Invalid IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar, causing segfault MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Invalid IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar, causing segfault --------------------------------------------------- Key: XERCESC-1961 URL: https://issues.apache.org/jira/browse/XERCESC-1961 Project: Xerces-C++ Issue Type: Bug Components: SAX/SAX2, Utilities, Validating Parser (DTD) Affects Versions: 2.6.0, 2.8.0 Environment: Linux, OpenVXI (http://sourceforge.net/projects/openvxi/) Reporter: Peter Burns The problem occurs while OpenVXI is initialising, when it parses a couple of (hard-coded) DTDs and then a (hard-coded) XSD. During the DTD parsing (SAX2XMLReader888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4parse()), a DTDGrammar is created and stored in two places: GrammarResolver888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4GrammarBucket and IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar. At the start of the XSG parsing (SAX2XMLReader888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadGrammar()), the GrammarBucket is cleared, deleting the DTDGrammar but leaving IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar still pointing to it. During the parsing, IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getEntityDeclPool() is called and hence tries to call fDTDGrammar->getEntityDeclPool(). This sometimes causes a segfault (though usually only after our app - performing these operations over and over - has been running for a few hours). I have some code which reproduces the problem - I'll attach it to this case as soon as I can work out how. Since the code rarely segfaults, I've been demonstrating it by adding printf()s to the DTDGrammar constructor/destructor and IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getEntityDeclPool(). So my test code currently generates this: [peter@ultra1 xerces_bug]$ ./test DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95691508 Warning in file vxml 1.0 defaults at line 2 column 51 Reason: Element 'metadata' was referenced in a content model but never declared DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95691508 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x956fa908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getEntityDeclPool() fDTDGrammar = 0x95691508 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x956fa908 [peter@ultra1 xerces_bug]$ showing the DTDGrammar this=0x95691508 being created, deleted and then used by IGXMLScanner. Our fix is to set fDTDGrammar to 0 after the bucket-clearing operation fGrammarResolver->useCachedGrammarInParse(toCache); at the start of IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadGrammar(), and this solves our problem. We've reproduced the problem in v2.6.0 and v2.7.0, but v3.1.1 doesn't call IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getEntityDeclPool() in our test code. However, tracing it in gdb I can see that v3.1.1 does potentially have the same problem, i.e. IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar is pointing to a deleted DTDGrammar after IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadGrammar() has cleared the cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Tue Apr 05 16:37:44 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 36789 invoked from network); 5 Apr 2011 16:37:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Apr 2011 16:37:44 -0000 Received: (qmail 90758 invoked by uid 500); 5 Apr 2011 16:37:44 -0000 Delivered-To: jasmine05@example.org Received: (qmail 90716 invoked by uid 500); 5 Apr 2011 16:37:43 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 90593 invoked by uid 99); 5 Apr 2011 16:37:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Apr 2011 16:37:43 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Apr 2011 16:37:42 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id C4DE69323D for <jasmine05@example.org>; Tue, 5 Apr 2011 16:37:05 +0000 (UTC) Date: Tue, 5 Apr 2011 16:37:05 +0000 (UTC) From: "Peter Burns (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> In-Reply-To: <jasmine05@example.org> Subject: [jira] [Updated] (XERCESC-1961) Invalid IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar, causing segfault MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/XERCESC-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Burns updated XERCESC-1961: --------------------------------- Attachment: 2011-04-05_xerces_bug.tar.gz Here's our test code: Schema.hpp is verbatim from the OpenVXI code; DTDResolver is from OpenVXI's DocumentParser.cpp. > Invalid IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar, causing segfault > --------------------------------------------------- > > Key: XERCESC-1961 > URL: https://issues.apache.org/jira/browse/XERCESC-1961 > Project: Xerces-C++ > Issue Type: Bug > Components: SAX/SAX2, Utilities, Validating Parser (DTD) > Affects Versions: 2.6.0, 2.8.0 > Environment: Linux, OpenVXI (http://sourceforge.net/projects/openvxi/) > Reporter: Peter Burns > Attachments: 2011-04-05_xerces_bug.tar.gz > > > The problem occurs while OpenVXI is initialising, when it parses a couple of (hard-coded) DTDs and then a (hard-coded) XSD. During the DTD parsing (SAX2XMLReader888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4parse()), a DTDGrammar is created and stored in two places: GrammarResolver888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4GrammarBucket and IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar. At the start of the XSG parsing (SAX2XMLReader888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadGrammar()), the GrammarBucket is cleared, deleting the DTDGrammar but leaving IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar still pointing to it. During the parsing, IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getEntityDeclPool() is called and hence tries to call fDTDGrammar->getEntityDeclPool(). This sometimes causes a segfault (though usually only after our app - performing these operations over and over - has been running for a few hours). > I have some code which reproduces the problem - I'll attach it to this case as soon as I can work out how. Since the code rarely segfaults, I've been demonstrating it by adding printf()s to the DTDGrammar constructor/destructor and IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getEntityDeclPool(). So my test code currently generates this: > [peter@ultra1 xerces_bug]$ ./test > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95691508 > Warning in file vxml 1.0 defaults at line 2 column 51 > Reason: Element 'metadata' was referenced in a content model but never declared > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95691508 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x956fa908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar() this = 0x95ac4908 > IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getEntityDeclPool() fDTDGrammar = 0x95691508 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x95ac4908 > DTDGrammar888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4~DTDGrammar() this = 0x956fa908 > [peter@ultra1 xerces_bug]$ > showing the DTDGrammar this=0x95691508 being created, deleted and then used by IGXMLScanner. > Our fix is to set fDTDGrammar to 0 after the bucket-clearing operation > fGrammarResolver->useCachedGrammarInParse(toCache); > at the start of IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadGrammar(), and this solves our problem. > We've reproduced the problem in v2.6.0 and v2.7.0, but v3.1.1 doesn't call IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4getEntityDeclPool() in our test code. However, tracing it in gdb I can see that v3.1.1 does potentially have the same problem, i.e. IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4TDGrammar is pointing to a deleted DTDGrammar after IGXMLScanner888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadGrammar() has cleared the cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Fri Apr 15 12:35:45 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 40180 invoked from network); 15 Apr 2011 12:35:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 15 Apr 2011 12:35:44 -0000 Received: (qmail 92730 invoked by uid 500); 15 Apr 2011 12:35:44 -0000 Delivered-To: jasmine05@example.org Received: (qmail 92677 invoked by uid 500); 15 Apr 2011 12:35:44 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 92670 invoked by uid 99); 15 Apr 2011 12:35:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 12:35:43 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 12:35:42 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id C2DCCA26A4 for <jasmine05@example.org>; Fri, 15 Apr 2011 12:35:05 +0000 (UTC) Date: Fri, 15 Apr 2011 12:35:05 +0000 (UTC) From: "Alberto Massari (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> Subject: [jira] [Assigned] (XERCESC-1935) Xerces 2.8 sax parser crashes for nested DTD inputs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/XERCESC-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari reassigned XERCESC-1935: ---------------------------------------- Assignee: Alberto Massari > Xerces 2.8 sax parser crashes for nested DTD inputs. > ---------------------------------------------------- > > Key: XERCESC-1935 > URL: https://issues.apache.org/jira/browse/XERCESC-1935 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) > Affects Versions: 2.8.0 > Environment: Linux 2.6.18-92.e165xen > Reporter: Sharda Khubchandani > Assignee: Alberto Massari > Attachments: sample_project.zip > > > Xerces parser crashes with attached sample -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Fri Apr 15 15:21:49 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 81005 invoked from network); 15 Apr 2011 15:21:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 15 Apr 2011 15:21:49 -0000 Received: (qmail 29803 invoked by uid 500); 15 Apr 2011 15:21:49 -0000 Delivered-To: jasmine05@example.org Received: (qmail 29737 invoked by uid 500); 15 Apr 2011 15:21:49 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 29729 invoked by uid 99); 15 Apr 2011 15:21:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 15:21:49 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 15:21:43 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id AE097A36AD for <jasmine05@example.org>; Fri, 15 Apr 2011 15:21:05 +0000 (UTC) Date: Fri, 15 Apr 2011 15:21:05 +0000 (UTC) From: "Alberto Massari (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> Subject: [jira] [Resolved] (XERCESC-1935) Xerces 2.8 sax parser crashes for nested DTD inputs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/XERCESC-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Massari resolved XERCESC-1935. -------------------------------------- Resolution: Fixed Fix Version/s: 3.2.0 2.9.0 A fix in SVN. Please verify. > Xerces 2.8 sax parser crashes for nested DTD inputs. > ---------------------------------------------------- > > Key: XERCESC-1935 > URL: https://issues.apache.org/jira/browse/XERCESC-1935 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (DTD) > Affects Versions: 2.8.0 > Environment: Linux 2.6.18-92.e165xen > Reporter: Sharda Khubchandani > Assignee: Alberto Massari > Fix For: 2.9.0, 3.2.0 > > Attachments: sample_project.zip > > > Xerces parser crashes with attached sample -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Fri Apr 15 20:30:49 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 99734 invoked from network); 15 Apr 2011 20:30:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 15 Apr 2011 20:30:49 -0000 Received: (qmail 20978 invoked by uid 500); 15 Apr 2011 20:30:49 -0000 Delivered-To: jasmine05@example.org Received: (qmail 20945 invoked by uid 500); 15 Apr 2011 20:30:49 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 20938 invoked by uid 99); 15 Apr 2011 20:30:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 20:30:49 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 20:30:43 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id B78C2A34E5 for <jasmine05@example.org>; Fri, 15 Apr 2011 20:30:05 +0000 (UTC) Date: Fri, 15 Apr 2011 20:30:05 +0000 (UTC) From: "Paulo Zanoni (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> Subject: [jira] [Created] (XERCESC-1962) memory leak with XInclude MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org memory leak with XInclude ------------------------- Key: XERCESC-1962 URL: https://issues.apache.org/jira/browse/XERCESC-1962 Project: Xerces-C++ Issue Type: Bug Components: XInclude Affects Versions: 3.1.1 Environment: Linux Ubuntu 10.10 i386 Reporter: Paulo Zanoni When xerces-c++ is parsing files with XInclude, it leaks memory. You can check the memory leak by running "valgrind". This behavior can be reproduced both with the "XInclude" binary and with custom code. All you need to do is: - create a parser - set validation scheme to Val_Auto - setDoNamespaces(true) - setDoXInclude(true) - parser.parse("example.xml"); I have tracked the bug. The "actual" leak is inside XIncludeUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4reportError. It uses XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadMsgSet, which calls loadAMsgSet, which allocates memory and returns to its callee (see XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadAMsgSet inside utils/PlatformUtils.cpp). The memory allocated by loadAMsgSet is never freed. The solution: In file xinclude/XIncludeUtils.cpp, function XIncludeUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4reportError, the pointer allocated by XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadMsgSet should be freed. For my testings, I just added a "delete erMsgLoader" at the end of the scope, but I am not sure this is enough (since I'm not sure if any of the functions between loadMsgSet and the end of the scope can throw exceptions). It is up to you, developers, find a proper solution =D I'll attach examples. I locally tested my patch (I rebuild the Ubuntu package) and it seems to have worked, but I didn't test much. I am not familiar with xerces-c code so I'm not sure if it can break anything. Thanks, Paulo -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Fri Apr 15 20:40:44 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 40810 invoked from network); 15 Apr 2011 20:40:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 15 Apr 2011 20:40:44 -0000 Received: (qmail 30143 invoked by uid 500); 15 Apr 2011 20:40:44 -0000 Delivered-To: jasmine05@example.org Received: (qmail 30118 invoked by uid 500); 15 Apr 2011 20:40:44 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 30105 invoked by uid 99); 15 Apr 2011 20:40:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 20:40:44 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 20:40:43 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id 5AA61A3806 for <jasmine05@example.org>; Fri, 15 Apr 2011 20:40:06 +0000 (UTC) Date: Fri, 15 Apr 2011 20:40:06 +0000 (UTC) From: "Paulo Zanoni (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> In-Reply-To: <jasmine05@example.org> Subject: [jira] [Updated] (XERCESC-1962) memory leak with XInclude MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/XERCESC-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Zanoni updated XERCESC-1962: ---------------------------------- Attachment: xinclude-example.xml xinclude_leak.cpp Files to reproduce the bug. Compile and run with valgrind --leak-check=full > memory leak with XInclude > ------------------------- > > Key: XERCESC-1962 > URL: https://issues.apache.org/jira/browse/XERCESC-1962 > Project: Xerces-C++ > Issue Type: Bug > Components: XInclude > Affects Versions: 3.1.1 > Environment: Linux Ubuntu 10.10 i386 > Reporter: Paulo Zanoni > Labels: example, leak, patch, > Attachments: xinclude-example.xml, xinclude_leak.cpp > > Original Estimate: 2h > Remaining Estimate: 2h > > When xerces-c++ is parsing files with XInclude, it leaks memory. You can check the memory leak by running "valgrind". > This behavior can be reproduced both with the "XInclude" binary and with custom code. > All you need to do is: > - create a parser > - set validation scheme to Val_Auto > - setDoNamespaces(true) > - setDoXInclude(true) > - parser.parse("example.xml"); > I have tracked the bug. The "actual" leak is inside XIncludeUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4reportError. It uses XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadMsgSet, which calls loadAMsgSet, which allocates memory and returns to its callee (see XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadAMsgSet inside utils/PlatformUtils.cpp). The memory allocated by loadAMsgSet is never freed. > The solution: > In file xinclude/XIncludeUtils.cpp, function XIncludeUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4reportError, the pointer allocated by XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadMsgSet should be freed. For my testings, I just added a "delete erMsgLoader" at the end of the scope, but I am not sure this is enough (since I'm not sure if any of the functions between loadMsgSet and the end of the scope can throw exceptions). It is up to you, developers, find a proper solution =D > I'll attach examples. > I locally tested my patch (I rebuild the Ubuntu package) and it seems to have worked, but I didn't test much. I am not familiar with xerces-c code so I'm not sure if it can break anything. > Thanks, > Paulo -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Fri Apr 15 20:44:53 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 41821 invoked from network); 15 Apr 2011 20:44:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 15 Apr 2011 20:44:49 -0000 Received: (qmail 36165 invoked by uid 500); 15 Apr 2011 20:44:49 -0000 Delivered-To: jasmine05@example.org Received: (qmail 36130 invoked by uid 500); 15 Apr 2011 20:44:49 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 36123 invoked by uid 99); 15 Apr 2011 20:44:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 20:44:49 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Apr 2011 20:44:44 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id 2FD4DA398C for <jasmine05@example.org>; Fri, 15 Apr 2011 20:44:06 +0000 (UTC) Date: Fri, 15 Apr 2011 20:44:06 +0000 (UTC) From: "Paulo Zanoni (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> In-Reply-To: <jasmine05@example.org> Subject: [jira] [Updated] (XERCESC-1962) memory leak with XInclude MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/XERCESC-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Zanoni updated XERCESC-1962: ---------------------------------- Attachment: xinclude-leak.patch Patch generated with "svn diff" I have no idea if it can have "side effects". Please audit it. > memory leak with XInclude > ------------------------- > > Key: XERCESC-1962 > URL: https://issues.apache.org/jira/browse/XERCESC-1962 > Project: Xerces-C++ > Issue Type: Bug > Components: XInclude > Affects Versions: 3.1.1 > Environment: Linux Ubuntu 10.10 i386 > Reporter: Paulo Zanoni > Labels: example, leak, patch, > Attachments: xinclude-example.xml, xinclude-leak.patch, xinclude_leak.cpp > > Original Estimate: 2h > Remaining Estimate: 2h > > When xerces-c++ is parsing files with XInclude, it leaks memory. You can check the memory leak by running "valgrind". > This behavior can be reproduced both with the "XInclude" binary and with custom code. > All you need to do is: > - create a parser > - set validation scheme to Val_Auto > - setDoNamespaces(true) > - setDoXInclude(true) > - parser.parse("example.xml"); > I have tracked the bug. The "actual" leak is inside XIncludeUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4reportError. It uses XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadMsgSet, which calls loadAMsgSet, which allocates memory and returns to its callee (see XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadAMsgSet inside utils/PlatformUtils.cpp). The memory allocated by loadAMsgSet is never freed. > The solution: > In file xinclude/XIncludeUtils.cpp, function XIncludeUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4reportError, the pointer allocated by XMLPlatformUtils888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4loadMsgSet should be freed. For my testings, I just added a "delete erMsgLoader" at the end of the scope, but I am not sure this is enough (since I'm not sure if any of the functions between loadMsgSet and the end of the scope can throw exceptions). It is up to you, developers, find a proper solution =D > I'll attach examples. > I locally tested my patch (I rebuild the Ubuntu package) and it seems to have worked, but I didn't test much. I am not familiar with xerces-c code so I'm not sure if it can break anything. > Thanks, > Paulo -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Sun Apr 17 21:59:44 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 35519 invoked from network); 17 Apr 2011 21:59:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 17 Apr 2011 21:59:44 -0000 Received: (qmail 14790 invoked by uid 500); 17 Apr 2011 21:59:43 -0000 Delivered-To: jasmine05@example.org Received: (qmail 14674 invoked by uid 500); 17 Apr 2011 21:59:43 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 14658 invoked by uid 99); 17 Apr 2011 21:59:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 21:59:43 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 21:59:42 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id B79BEA6F10 for <jasmine05@example.org>; Sun, 17 Apr 2011 21:59:05 +0000 (UTC) Date: Sun, 17 Apr 2011 21:59:05 +0000 (UTC) From: "Eric Swalens (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> Subject: [jira] [Created] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Custom HTTP headers missing with CURL NetAccessor -------------------------------------------------- Key: XERCESC-1963 URL: https://issues.apache.org/jira/browse/XERCESC-1963 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 3.1.1 Environment: Xerces-c 3.1.1, Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 Reporter: Eric Swalens Priority: Minor Attachments: CurlURLInputStream-headers-0.1.patch It seems that the custom headers set using XMLNetHTTPInfo are missing from the actual HTTP request when the CURLNetAccessor is used. The SocketNetAccessor does not show this problem. The headerList in the CurlURLInputStream constructor is correctly built but from what I understand of the CURL documentation the list cannot be freed until the GET request has been made. Currently the list feed right after setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the destructor solves the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Sun Apr 17 21:59:44 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 35518 invoked from network); 17 Apr 2011 21:59:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 17 Apr 2011 21:59:44 -0000 Received: (qmail 14780 invoked by uid 500); 17 Apr 2011 21:59:43 -0000 Delivered-To: jasmine05@example.org Received: (qmail 14672 invoked by uid 500); 17 Apr 2011 21:59:43 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 14663 invoked by uid 99); 17 Apr 2011 21:59:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 21:59:43 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 21:59:42 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id BE1B4A6F11 for <jasmine05@example.org>; Sun, 17 Apr 2011 21:59:05 +0000 (UTC) Date: Sun, 17 Apr 2011 21:59:05 +0000 (UTC) From: "Eric Swalens (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> In-Reply-To: <jasmine05@example.org> Subject: [jira] [Updated] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/XERCESC-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Swalens updated XERCESC-1963: ---------------------------------- Attachment: CurlURLInputStream-headers-0.1.patch > Custom HTTP headers missing with CURL NetAccessor > -------------------------------------------------- > > Key: XERCESC-1963 > URL: https://issues.apache.org/jira/browse/XERCESC-1963 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities > Affects Versions: 3.1.1 > Environment: Xerces-c 3.1.1, Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 > Reporter: Eric Swalens > Priority: Minor > Labels: patch > Attachments: CurlURLInputStream-headers-0.1.patch > > > It seems that the custom headers set using XMLNetHTTPInfo are missing from the actual HTTP request when the CURLNetAccessor is used. The SocketNetAccessor does not show this problem. > The headerList in the CurlURLInputStream constructor is correctly built but from what I understand of the CURL documentation the list cannot be freed until the GET request has been made. Currently the list feed right after setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the destructor solves the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Sun Apr 17 22:03:46 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 65958 invoked from network); 17 Apr 2011 22:03:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 17 Apr 2011 22:03:46 -0000 Received: (qmail 17036 invoked by uid 500); 17 Apr 2011 22:03:46 -0000 Delivered-To: jasmine05@example.org Received: (qmail 16997 invoked by uid 500); 17 Apr 2011 22:03:46 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 16984 invoked by uid 99); 17 Apr 2011 22:03:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 22:03:46 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO hel.zones.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 22:03:44 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [83.161.120.155]) by hel.zones.apache.org (Postfix) with ESMTP id 252A6A6FBB for <jasmine05@example.org>; Sun, 17 Apr 2011 22:03:06 +0000 (UTC) Date: Sun, 17 Apr 2011 22:03:06 +0000 (UTC) From: "Eric Swalens (JIRA)" <jasmine05@example.org> To: jasmine05@example.org Message-ID: <jasmine05@example.org> In-Reply-To: <jasmine05@example.org> Subject: [jira] [Updated] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/XERCESC-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Swalens updated XERCESC-1963: ---------------------------------- Description: It seems that the custom headers set using XMLNetHTTPInfo are missing from the actual HTTP request when the CURLNetAccessor is used. The SocketNetAccessor does not show this problem. The headerList in the CurlURLInputStream constructor is correctly built but from what I understand of the CURL documentation the list cannot be freed until the GET request has been made. Currently the list feed right after setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the destructor solves the issue (patch attached). was: It seems that the custom headers set using XMLNetHTTPInfo are missing from the actual HTTP request when the CURLNetAccessor is used. The SocketNetAccessor does not show this problem. The headerList in the CurlURLInputStream constructor is correctly built but from what I understand of the CURL documentation the list cannot be freed until the GET request has been made. Currently the list feed right after setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the destructor solves the issue. Environment: Xerces-c 3.1.1 curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 was:Xerces-c 3.1.1, Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 > Custom HTTP headers missing with CURL NetAccessor > -------------------------------------------------- > > Key: XERCESC-1963 > URL: https://issues.apache.org/jira/browse/XERCESC-1963 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities > Affects Versions: 3.1.1 > Environment: Xerces-c 3.1.1 > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 > Reporter: Eric Swalens > Priority: Minor > Labels: patch > Attachments: CurlURLInputStream-headers-0.1.patch > > > It seems that the custom headers set using XMLNetHTTPInfo are missing from the actual HTTP request when the CURLNetAccessor is used. The SocketNetAccessor does not show this problem. > The headerList in the CurlURLInputStream constructor is correctly built but from what I understand of the CURL documentation the list cannot be freed until the GET request has been made. Currently the list feed right after setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the destructor solves the issue (patch attached). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Sun Apr 17 22:33:06 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 54879 invoked from network); 17 Apr 2011 22:33:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 17 Apr 2011 22:33:06 -0000 Received: (qmail 28486 invoked by uid 500); 17 Apr 2011 22:33:06 -0000 Delivered-To: jasmine05@example.org Received: (qmail 28451 invoked by uid 500); 17 Apr 2011 22:33:06 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 28442 invoked by uid 99); 17 Apr 2011 22:33:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 22:33:06 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO mail-ww0-f41.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 22:33:00 +0000 Received: by wwi18 with SMTP id 18so1256589wwi.2 for <jasmine05@example.org>; Sun, 17 Apr 2011 15:32:38 -0700 (PDT) Received: by 83.161.120.155 with SMTP id p24mr9647659wej.97.1303079558002; Sun, 17 Apr 2011 15:32:38 -0700 (PDT) Received: from jpcsmac.lan (188-220-141-149.zone11.bethere.co.uk [83.161.120.155]) by mx.google.com with ESMTPS id t5sm2308613wes.33.283.161.120.155.32.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Apr 2011 15:32:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) Subject: Re: [jira] [Updated] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor From: John Snelson <jasmine05@example.org> In-Reply-To: <jasmine05@example.org> Date: Sun, 17 Apr 2011 23:32:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <jasmine05@example.org> References: <jasmine05@example.org> To: jasmine05@example.org X-Mailer: Apple Mail (2.1081) Hi all, I'd like to handle this - I think I was probably the last person working = in this area of the code. My only problem is it's been a while, and I've changed jobs and email = addresses since the last time I logged in anywhere! Can someone get my = email address in the system changed to this one, so that I can log into = JIRA again and take a proper look at resolving this bug? Thanks, John Snelson On 17 Apr 2011, at 23:03, Eric Swalens (JIRA) wrote: >=20 > [ = https://issues.apache.org/jira/browse/XERCESC-1963?page=3Dcom.atlassian.ji= ra.plugin.system.issuetabpanels:all-tabpanel ] >=20 > Eric Swalens updated XERCESC-1963: > ---------------------------------- >=20 > Description:=20 > It seems that the custom headers set using XMLNetHTTPInfo are missing = from the actual HTTP request when the CURLNetAccessor is used. The = SocketNetAccessor does not show this problem. >=20 > The headerList in the CurlURLInputStream constructor is correctly = built but from what I understand of the CURL documentation the list = cannot be freed until the GET request has been made. Currently the list = feed right after setting the CURLOPT_HTTPHEADER. Delaying the call = curl_slist_free_all to the destructor solves the issue (patch attached). >=20 > was: > It seems that the custom headers set using XMLNetHTTPInfo are missing = from the actual HTTP request when the CURLNetAccessor is used. The = SocketNetAccessor does not show this problem. >=20 > The headerList in the CurlURLInputStream constructor is correctly = built but from what I understand of the CURL documentation the list = cannot be freed until the GET request has been made. Currently the list = feed right after setting the CURLOPT_HTTPHEADER. Delaying the call = curl_slist_free_all to the destructor solves the issue. >=20 > Environment:=20 > Xerces-c 3.1.1 > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >=20 > was:Xerces-c 3.1.1, Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >=20 >=20 >> Custom HTTP headers missing with CURL NetAccessor=20 >> -------------------------------------------------- >>=20 >> Key: XERCESC-1963 >> URL: = https://issues.apache.org/jira/browse/XERCESC-1963 >> Project: Xerces-C++ >> Issue Type: Bug >> Components: Utilities >> Affects Versions: 3.1.1 >> Environment: Xerces-c 3.1.1 >> curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 >> Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >> Reporter: Eric Swalens >> Priority: Minor >> Labels: patch >> Attachments: CurlURLInputStream-headers-0.1.patch >>=20 >>=20 >> It seems that the custom headers set using XMLNetHTTPInfo are missing = from the actual HTTP request when the CURLNetAccessor is used. The = SocketNetAccessor does not show this problem. >> The headerList in the CurlURLInputStream constructor is correctly = built but from what I understand of the CURL documentation the list = cannot be freed until the GET request has been made. Currently the list = feed right after setting the CURLOPT_HTTPHEADER. Delaying the call = curl_slist_free_all to the destructor solves the issue (patch attached). >=20 > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: = http://www.atlassian.com/software/jira >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: jasmine05@example.org > For additional commands, e-mail: jasmine05@example.org >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: jasmine05@example.org For additional commands, e-mail: jasmine05@example.org From jasmine05@example.org Mon Apr 18 00:31:56 2011 Return-Path: <jasmine05@example.org> Delivered-To: jasmine05@example.org Received: (qmail 27686 invoked from network); 18 Apr 2011 00:31:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 18 Apr 2011 00:31:56 -0000 Received: (qmail 86680 invoked by uid 500); 18 Apr 2011 00:31:56 -0000 Delivered-To: jasmine05@example.org Received: (qmail 86655 invoked by uid 500); 18 Apr 2011 00:31:56 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 86648 invoked by uid 99); 18 Apr 2011 00:31:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Apr 2011 00:31:56 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jasmine05@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO e3.ny.us.ibm.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Apr 2011 00:31:48 +0000 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [83.161.120.155]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p3I0AIH9007514 for <jasmine05@example.org>; Sun, 17 Apr 2011 20:10:18 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [83.161.120.155]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3I0VPbK2724036 for <jasmine05@example.org>; Sun, 17 Apr 2011 20:31:25 -0400 Received: from d01av01.pok.ibm.com (loopback [83.161.120.155]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3I0VPUo012970 for <jasmine05@example.org>; Sun, 17 Apr 2011 20:31:25 -0400 Received: from d25ml03.torolab.ibm.com (d25ml03.torolab.ibm.com [83.161.120.155]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3I0VOgt012958 for <jasmine05@example.org>; Sun, 17 Apr 2011 20:31:24 -0400 In-Reply-To: <jasmine05@example.org> References: <jasmine05@example.org> <jasmine05@example.org> Subject: Re: [jira] [Updated] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor X-KeepSent: DFAB3F2B:52719A08-85257876:0002590D; type=4; name=$KeepSent To: jasmine05@example.org X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: <jasmine05@example.org> From: Michael Glavassevich <jasmine05@example.org> Date: Sun, 17 Apr 2011 20:31:24 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.5.1FP5|September 29, 2010) at 04/17/2011 20:31:24 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF2E5DF91DF9D8f9e8a93df938690918c0ABBF2E5DF91DF9D" Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org --0__=0ABBF2E5DF91DF9D8f9e8a93df938690918c0ABBF2E5DF91DF9D Content-type: text/plain; charset=US-ASCII Hi John, I would suggest contacting the Infrastructure team. I believe they're the only ones who could make that kind of update to an account. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: jasmine05@example.org E-mail: jasmine05@example.org John Snelson <jasmine05@example.org> wrote on 04/17/2011 06:32:34 PM: > Hi all, > > I'd like to handle this - I think I was probably the last person > working in this area of the code. > > My only problem is it's been a while, and I've changed jobs and > email addresses since the last time I logged in anywhere! Can > someone get my email address in the system changed to this one, so > that I can log into JIRA again and take a proper look at resolving this bug? > > Thanks, > > John Snelson > > On 17 Apr 2011, at 23:03, Eric Swalens (JIRA) wrote: > > > > > [ https://issues.apache.org/jira/browse/XERCESC-1963? > page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > > > Eric Swalens updated XERCESC-1963: > > ---------------------------------- > > > > Description: > > It seems that the custom headers set using XMLNetHTTPInfo are > missing from the actual HTTP request when the CURLNetAccessor is > used. The SocketNetAccessor does not show this problem. > > > > The headerList in the CurlURLInputStream constructor is correctly > built but from what I understand of the CURL documentation the list > cannot be freed until the GET request has been made. Currently the > list feed right after setting the CURLOPT_HTTPHEADER. Delaying the > call curl_slist_free_all to the destructor solves the issue (patch attached). > > > > was: > > It seems that the custom headers set using XMLNetHTTPInfo are > missing from the actual HTTP request when the CURLNetAccessor is > used. The SocketNetAccessor does not show this problem. > > > > The headerList in the CurlURLInputStream constructor is correctly > built but from what I understand of the CURL documentation the list > cannot be freed until the GET request has been made. Currently the > list feed right after setting the CURLOPT_HTTPHEADER. Delaying the > call curl_slist_free_all to the destructor solves the issue. > > > > Environment: > > Xerces-c 3.1.1 > > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 > > > > was:Xerces-c 3.1.1, Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 > > > > > >> Custom HTTP headers missing with CURL NetAccessor > >> -------------------------------------------------- > >> > >> Key: XERCESC-1963 > >> URL: https://issues.apache.org/jira/browse/XERCESC-1963 > >> Project: Xerces-C++ > >> Issue Type: Bug > >> Components: Utilities > >> Affects Versions: 3.1.1 > >> Environment: Xerces-c 3.1.1 > >> curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > >> Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 > >> Reporter: Eric Swalens > >> Priority: Minor > >> Labels: patch > >> Attachments: CurlURLInputStream-headers-0.1.patch > >> > >> > >> It seems that the custom headers set using XMLNetHTTPInfo are > missing from the actual HTTP request when the CURLNetAccessor is > used. The SocketNetAccessor does not show this problem. > >> The headerList in the CurlURLInputStream constructor is correctly > built but from what I understand of the CURL documentation the list > cannot be freed until the GET request has been made. Currently the > list feed right after setting the CURLOPT_HTTPHEADER. Delaying the > call curl_slist_free_all to the destructor solves the issue (patch attached). > > > > -- > > This message is automatically generated by JIRA. > > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: jasmine05@example.org > > For additional commands, e-mail: jasmine05@example.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jasmine05@example.org > For additional commands, e-mail: jasmine05@example.org --0__=0ABBF2E5DF91DF9D8f9e8a93df938690918c0ABBF2E5DF91DF9D Content-type: text/html; charset=US-ASCII Content-Disposition: inline <html><body> <p><tt>Hi John,</tt><br> <br> <tt>I would suggest contacting the Infrastructure team. I believe they're the only ones who could make that kind of update to an account.</tt><br> <br> <tt>Thanks.</tt><br> <br> <tt>Michael Glavassevich<br> XML Parser Development<br> IBM Toronto Lab<br> E-mail: jasmine05@example.org</tt><br> <tt>E-mail: jasmine05@example.org</tt><br> <br> <tt>John Snelson &lt;jasmine05@example.org&gt; wrote on 04/17/2011 06:32:34 PM:<br> <br> &gt; Hi all,<br> &gt; <br> &gt; I'd like to handle this - I think I was probably the last person <br> &gt; working in this area of the code.<br> &gt; <br> &gt; My only problem is it's been a while, and I've changed jobs and <br> &gt; email addresses since the last time I logged in anywhere! Can <br> &gt; someone get my email address in the system changed to this one, so <br> &gt; that I can log into JIRA again and take a proper look at resolving this bug?<br> &gt; <br> &gt; Thanks,<br> &gt; <br> &gt; John Snelson<br> &gt; <br> &gt; On 17 Apr 2011, at 23:03, Eric Swalens (JIRA) wrote:<br> &gt; <br> &gt; &gt; <br> &gt; &gt; &nbsp; &nbsp; [ <a href="https://issues.apache.org/jira/browse/XERCESC-1963?">https://issues.apache.org/jira/browse/XERCESC-1963?</a><br> &gt; page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]<br> &gt; &gt; <br> &gt; &gt; Eric Swalens updated XERCESC-1963:<br> &gt; &gt; ----------------------------------<br> &gt; &gt; <br> &gt; &gt; &nbsp; &nbsp;Description: <br> &gt; &gt; It seems that the custom headers set using XMLNetHTTPInfo are <br> &gt; missing from the actual HTTP request when the CURLNetAccessor is <br> &gt; used. The SocketNetAccessor does not show this problem.<br> &gt; &gt; <br> &gt; &gt; The headerList in the CurlURLInputStream constructor is correctly <br> &gt; built but from what I understand of the CURL documentation the list <br> &gt; cannot be freed until the GET request has been made. Currently the <br> &gt; list feed right after setting the CURLOPT_HTTPHEADER. Delaying the <br> &gt; call curl_slist_free_all to the destructor solves the issue (patch attached).<br> &gt; &gt; <br> &gt; &gt; &nbsp;was:<br> &gt; &gt; It seems that the custom headers set using XMLNetHTTPInfo are <br> &gt; missing from the actual HTTP request when the CURLNetAccessor is <br> &gt; used. The SocketNetAccessor does not show this problem.<br> &gt; &gt; <br> &gt; &gt; The headerList in the CurlURLInputStream constructor is correctly <br> &gt; built but from what I understand of the CURL documentation the list <br> &gt; cannot be freed until the GET request has been made. Currently the <br> &gt; list feed right after setting the CURLOPT_HTTPHEADER. Delaying the <br> &gt; call curl_slist_free_all to the destructor solves the issue.<br> &gt; &gt; <br> &gt; &gt; &nbsp; &nbsp;Environment: <br> &gt; &gt; Xerces-c 3.1.1<br> &gt; &gt; curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3<br> &gt; &gt; Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1<br> &gt; &gt; <br> &gt; &gt; &nbsp;was:Xerces-c 3.1.1, Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1<br> &gt; &gt; <br> &gt; &gt; <br> &gt; &gt;&gt; Custom HTTP headers missing with CURL NetAccessor <br> &gt; &gt;&gt; --------------------------------------------------<br> &gt; &gt;&gt; <br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Key: XERCESC-1963<br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;URL: <a href="https://issues.apache.org/jira/browse/XERCESC-1963">https://issues.apache.org/jira/browse/XERCESC-1963</a><br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Project: Xerces-C++<br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; Issue Type: Bug<br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; Components: Utilities<br> &gt; &gt;&gt; &nbsp; Affects Versions: 3.1.1<br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp;Environment: Xerces-c 3.1.1<br> &gt; &gt;&gt; curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3<br> &gt; &gt;&gt; Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1<br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Reporter: Eric Swalens<br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Priority: Minor<br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Labels: patch<br> &gt; &gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp;Attachments: CurlURLInputStream-headers-0.1.patch<br> &gt; &gt;&gt; <br> &gt; &gt;&gt; <br> &gt; &gt;&gt; It seems that the custom headers set using XMLNetHTTPInfo are <br> &gt; missing from the actual HTTP request when the CURLNetAccessor is <br> &gt; used. The SocketNetAccessor does not show this problem.<br> &gt; &gt;&gt; The headerList in the CurlURLInputStream constructor is correctly<br> &gt; built but from what I understand of the CURL documentation the list <br> &gt; cannot be freed until the GET request has been made. Currently the <br> &gt; list feed right after setting the CURLOPT_HTTPHEADER. Delaying the <br> &gt; call curl_slist_free_all to the destructor solves the issue (patch attached).<br> &gt; &gt; <br> &gt; &gt; --<br> &gt; &gt; This message is automatically generated by JIRA.<br> &gt; &gt; For more information on JIRA, see: <a href="http://www.atlassian.com/software/jira">http://www.atlassian.com/software/jira</a><br> &gt; &gt; <br> &gt; &gt; ---------------------------------------------------------------------<br> &gt; &gt; To unsubscribe, e-mail: jasmine05@example.org<br> &gt; &gt; For additional commands, e-mail: jasmine05@example.org<br> &gt; &gt; <br> &gt; <br> &gt; <br> &gt; ---------------------------------------------------------------------<br> &gt; To unsubscribe, e-mail: jasmine05@example.org<br> &gt; For additional commands, e-mail: jasmine05@example.org</tt></body></html> --0__=0ABBF2E5DF91DF9D8f9e8a93df938690918c0ABBF2E5DF91DF9D-- From jasmine05@example.org Wed Apr 27 07:26:57 2011 Return-Path: <jasmine05@example.org> X-Original-To: jasmine05@example.org Delivered-To: jasmine05@example.org Received: from mail.apache.org (hermes.apache.org [83.161.120.155]) by minotaur.apache.org (Postfix) with SMTP id 9153E24FF for <jasmine05@example.org>; Wed, 27 Apr 2011 07:26:57 +0000 (UTC) Received: (qmail 7807 invoked by uid 500); 27 Apr 2011 07:26:56 -0000 Delivered-To: jasmine05@example.org Received: (qmail 7593 invoked by uid 500); 27 Apr 2011 07:26:50 -0000 Mailing-List: contact jasmine05@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:jasmine05@example.org> List-Unsubscribe: <mailto:jasmine05@example.org> List-Post: <mailto:jasmine05@example.org> List-Id: <c-dev.xerces.apache.org> Reply-To: jasmine05@example.org Delivered-To: mailing list jasmine05@example.org Received: (qmail 7575 invoked by uid 99); 27 Apr 2011 07:26:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP;
{'source': 'Apache Software Foundation Public Mail Archives'}