Actually the crash is heppning in the destructor of FunctionName
FunctionName::~FunctionName()
DeleteFunctor<Function>::operator()(const Function*) const(0x2ff214c4,
0x2135affc)
demangle is something c++ uses to construct unique function names.
to get the exact funciton definition you can use c++filt.
I don't really understand why it is crashing in the destructor of
FunctionName.
It is happening after the transformation went through successfully.
Please let me know if there is any problem.
Thanks,
Raj..
> -----Original Message-----
> From: Avula, Raj
> Sent: Monday, March 25, 2002 2:34 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: problem with XPathFunctionTable::DestroyTable()
>
> Hi Dave,
> Thanks for the reply.
> I understand that there is no difference in pre-inc & post-inc in this
> case.
> But by the time _f(*__first) is called, pointer is already
> incremented(goes
> to second Function)
> which leaves first Function* undeleted.
>
> Raj..
>
> > -----Original Message-----
> > From: David N Bertoni/Cambridge/IBM
> [SMTP:[EMAIL PROTECTED]]
> > Sent: Monday, March 25, 2002 2:29 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: problem with XPathFunctionTable::DestroyTable()
> >
> >
> > I don't think there's anything wrong with that implementation of
> for_each
> > (). What "pre-increment" are you talking about? I see a for loop with
> no
> > for-init-statement, a valid condition, and an expression that increments
> > __first. There no different between:
> >
> > for ( ; __first != __last; ++__first)
> > __f(*__first);
> >
> >
> > and
> >
> > for ( ; __first != __last; __first++)
> > __f(*__first);
> >
> > except that using pre-increment is more efficient when an iterator is
> not
> > a
> > pointer.
> >
> >
> > Segmentation fault in demangle.__dt__12FunctionNameFv at 0xd075c38c
> > ($t1)
> > 0xd075c38c (__dt__12FunctionNameFv+0x40) 807f0008 lwz
> > r3,0x8(r31)
> >
> > I don't understand why the code is in a function beginning with
> > "demangle".
> > Is the some weird issue with the debugger? Put a breakpoint in the
> > destructor of XPathFunctionTable and make sure it's not being entered a
> > second time.
> >
> > I've built and tested the latest code on both xlC 3.6.6 and xlC 5.02 and
> > had no problems, so something must be going on in your code.
> >
> > Dave
> >
> >
> >
> >
> >
> > "Avula, Raj"
> >
> > <RAvula@firstam. To:
> > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> >
> > com> cc: (bcc: David N
> > Bertoni/Cambridge/IBM)
> >
> > Subject: problem with
> > XPathFunctionTable::DestroyTable()
> >
> > 03/25/2002 02:11
> >
> > PM
> >
> > Please respond
> >
> > to xalan-dev
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > for_each(m_FunctionCollection.begin(),
> > m_FunctionCollection.end(),
> > DeleteFunctorType());
> >
> >
> > The above call should be for deleting the vector of Function
> > pointers(vector<Function*>).
> > But if you see for_each function
> > ----------------
> > template <class _InputIter, class _Function>
> > _Function for_each(_InputIter __first, _InputIter __last, _Function __f)
> {
> > for ( ; __first != __last; ++__first)
> > __f(*__first);
> > return __f;
> > }
> > ------------
> >
> > It is pre-incrementing Function pointer. So first one will not be
> deleted.
> >
> > To my knowledge it looks like a leak.
> > Here is the core. I am not sure, if the below core is related to the
> above
> > problem.
> >
> > Type 'help' for help.
> > reading symbolic information ...
> > [using memory image in core]
> >
> > Segmentation fault in demangle.__dt__12FunctionNameFv at 0xd075c38c
> ($t1)
> > 0xd075c38c (__dt__12FunctionNameFv+0x40) 807f0008 lwz
> r3,0x8(r31)
> > (dbx) where
> > demangle.__dt__12FunctionNameFv() at 0xd075c38c
> > __cl__13DeleteFunctorXT8Function_CFPC8Function(0x2ff214c4, 0x2135affc)
> at
> > 0xd45e511c
> > for_each__FPP8FunctionT113DeleteFunctorXT8Function_(0x2ff214e0,
> > 0x2139ef18,
> > 0x2139ef90, 0xf21520f0) at 0
> > xd44e8e94
> > DestroyTable__18XPathFunctionTableFv() at 0xd471a3d4
> > __dt__18XPathFunctionTableFv() at 0xd4719744
> >
> __sterm_x_2fhome_2fravula_2fxml_2fxml_2dxalan_2fc_2fsrc_2fXPath_2fXPath_2e
> > cp
> >
> > p__Fi() at 0xd4714988
> > __C_runtime_termination() at 0x10000680
> > cuexit.exit(??) at 0xd0177c40
> > doTransformation(const int)(0x2ff227d0, 0x2), line 108 in
> > "CTestXSTransform.cc"
> > unnamed block $b21, line 33 in "CXSTestMain.cc"
> > main(argc = 1, argv = 0x2ff22868), line 33 in "CXSTestMain.cc"
> > (dbx)
> >
> >
> > Thanks,
> > Raj..
> >
> >
> >
> >
> >
>
> "MMS <firstam.com>" made the following
> annotations on 03/25/02 14:35:36
> --------------------------------------------------------------------------
> ----
> "THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED
> SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN
> CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE
> ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS
> MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE
> THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS
> MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE
> THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM."
>
> ==========================================================================
> ====
>
"MMS <firstam.com>" made the following
annotations on 03/25/02 15:39:17
------------------------------------------------------------------------------
"THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE
USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR
PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR
RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE,
DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE
THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS
MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM."
==============================================================================
