Geoffrey Winn wrote:
Jean-Sebastian,
I've stepped through the code and I believe the problem arises because
of an incorrect check for a reference counted pointer being null.
However, I can't reproduce this particular problem so could you try
applying the patch that I've attached to this note and let me know if
it helps? I've run it against the usual SDO test suite so at least it
shouldn't do any harm.
Geoff.
On 08/09/06, *Geoffrey Winn* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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]
<mailto:[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]
<mailto:[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]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Geoff,
Thanks! I'm now ready to test again on Windows with VC++ express 2005,
but for some reason I can't get the attachment out of this email. Could
you please attach it to a JIRA issue, or can it be committed directly if
as you say it doesn't do any harm? Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
