That code is called frequently in the SDo test suite so I've been stepping
through it in the debugger to try to get a feel for what it is doing. At the
moment the execution sequence I'm seeing makes no sense. If I step over the
line
unset((*i).first);
I'd expect to reach the if statement on the following line. In fact the
debugger jumps to the
PropertyValueMap::iterator i = PropertyValues.begin();
which doesn't make much sense. This is true whether I use the Microsoft or
stdcxx libraries. Since this is happening in a destructor I'm wondering if
maybe something has been deallocated too soon. Anyway,
1. I can't immediately see anything wrong with the use of the iterator
2. I'm looking into it.
Geoff.
On 07/09/06, Geoffrey Winn <[EMAIL PROTECTED]> wrote:
Jean-Sebastian,
By an odd coincidence I'm currently looking at a list iterator bug in SDO
that is exposed when I build against the stdcxx library rather than the
standard Microsoft one. Is thsi issue urgent? If possible I'd like to
re-visit your case after I've resolved the stdcxx one (hopefully later
today) By then I might understand it all :-)
On 07/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Jean-Sebastien Delfino wrote:
> [snip]
>
> > I just tried it and was able to import our VC7 solution into it. I ran
> > into two issues:
> > - A minor issue, I had to remove the ODBC libraries from the link
> > configuration
> > - A more serious issue, the SDO runtime breaks with exceptions
> > complaining about "incompatible list iterators" in
> > DataObjectImpl::~DataObjectImpl()
> >
> > This is probably easy to fix - although I have no idea how to fix it
> :)
> >
> Geoff,
>
> Here's the Exception and call stack I'm getting from sdo_test on
> Windows, built with VC++ Express 2005:
>
> msvcp80d.dll!104f9961()
> [Frames below may be incorrect and/or missing, no symbols loaded
> for msvcp80d.dll]
> >
>
> tuscany_sdo.dll!std::list<commonj::sdo::rdo,std::allocator<commonj::sdo::rdo>
> >::_Const_iterator<1>::_Compat(const
> std::list<commonj::sdo::rdo,std::allocator<commonj::sdo::rdo>
> >::_Const_iterator<1> & _Right={first=3452816845 second={...} }) Line
> 309 + 0x17 bytes C++
>
>
> tuscany_sdo.dll!std::list<commonj::sdo::rdo,std::allocator<commonj::sdo::rdo>
> >::_Const_iterator<1>::operator==(const
> std::list<commonj::sdo::rdo,std::allocator<commonj::sdo::rdo>
> >::_Const_iterator<1> & _Right={first=3452816845 second={...} }) Line
> 290 C++
> tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
> Line 4564 + 0x37 bytes C++
> tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
> destructor'() + 0x2b bytes C++
> tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef() Line
> 69 + 0x4c bytes C++
>
>
>
sdo_test.exe!commonj::sdo::RefCountingPointer<commonj::sdo::DataObject>::~RefCountingPointer<commonj::sdo::DataObject>()
> Line 133 + 0x15 bytes C++
> sdo_test.exe!sdotest::scopetest() Line 69 + 0x19 bytes C++
> sdo_test.exe!main(int argc=1, char * * argv=0x00386018) Line 48 +
> 0x5 bytes C++
> sdo_test.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
> sdo_test.exe!mainCRTStartup() Line 403 C
>
> The exception is raised in list.cpp - line 309:
> #if _HAS_ITERATOR_DEBUGGING
> void _Compat(const _Myt_iter& _Right) const
> { // test for compatible iterator pair
> if (this->_Mycont == 0 || this->_Mycont != _Right._Mycont)
> {
> _DEBUG_ERROR("list iterators incompatible"); <---- There
> _SCL_SECURE_TRAITS_INVALID_ARGUMENT;
> }
> }
>
> This is called from DataObjectImpl::~DataObjectImpl():
> PropertyValueMap::iterator i = PropertyValues.begin();
> while (i != PropertyValues.end())
> {
> unset((*i).first);
> if (i == PropertyValues.begin()) <-- There
> {
> // unset has not removed the item from the list - do it
> // here instead
> PropertyValues.erase(i);
> }
> i = PropertyValues.begin ();
> }
>
> And I am a little puzzled by the code in the above loop... Although I
> didn't spend much time trying to grasp the logic here, and I have not
> been playing with C++ iterators too much lately, my experience is that
> removing entries from a collection that you're iterating on is usually a
> sure way to shoot yourself in the foot :) so I may be wrong but I sense
> a bug somewhere in this loop...
>
> Could you please take a look and see if there's a quick fix for this?
> Thanks.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
