Re: Exception in SDO runtime on Windows, was: [C++] windows build system

2006-09-12 Thread Jean-Sebastien Delfino

Geoffrey Winn wrote:
Hi. I've created JIRA 719 describing this issue and attached the patch 
file

to it.

Geoff.

On 12/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:



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]






Thanks, trying it now...

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Exception in SDO runtime on Windows, was: [C++] windows build system

2006-09-12 Thread Geoffrey Winn

Hi. I've created JIRA 719 describing this issue and attached the patch file
to it.

Geoff.

On 12/09/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:



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]




Re: Exception in SDO runtime on Windows, was: [C++] windows build system

2006-09-12 Thread Jean-Sebastien Delfino

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] 
> 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]
> 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
>::_Const_iterator<1>::_Compat(const
std::list
>::_Const_iterator<1> & _Right={first=3452816845
second={...} })  Line
309 + 0x17 bytesC++


tuscany_sdo.dll!std::list
>::_Const_iterator<1>::operator==(const
std::list
>::_Const_iterator<1> & _Right={first=3452816845
second={...} })  Line
290C++

tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()


Line 4564 + 0x37 bytesC++
 tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar
deleting
destructor'()  + 0x2b bytesC++

tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef()  Line

69 + 0x4c bytesC++


sdo_test.exe!commonj::sdo::RefCountingPointer::~RefCountingPointer()
Line 133 + 0x15 bytesC++
 sdo_test.exe!sdotest::scopetest()  Line 69 + 0x19
bytesC++
 sdo_test.exe!main(int argc=1, char * *
argv=0x00386018)  Line 48 +
0x5 bytesC++
 sdo_test.exe!__tmainCRTStartup()  Line 586 + 0x19
bytesC
 sdo_test.exe!mainCRTStartup()  Line 403C

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();
   

Re: Exception in SDO runtime on Windows, was: [C++] windows build system

2006-09-08 Thread Geoffrey Winn
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]> 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 iterator2. 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 onWindows, 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 >::_Const_iterator<1>::_Compat(conststd::list
 >::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line309 + 0x17 bytesC++tuscany_sdo.dll!std::list >::_Const_iterator<1>::operator==(const
std::list >::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line290C++ tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++ tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deletingdestructor'()  + 0x2b bytesC++ tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef()  Line


69 + 0x4c bytesC++sdo_test.exe!commonj::sdo::RefCountingPointer::~RefCountingPointer()Line 133 + 0x15 bytesC++ sdo_test.exe!sdotest::scopetest()  Line 69 + 0x19 bytesC++
 sdo_test.exe!main(int argc=1, char * * argv=0x00386018)  Line 48 +0x5 bytesC++ sdo_test.exe!__tmainCRTStartup()  Line 586 + 0x19 bytesC sdo_test.exe!mainCRTStartup()  Line 403C


The exception is raised in list.cpp - line 309: #if _HAS_ITERATOR_DEBUGGINGvoid _Compat(const _Myt_iter& _Right) const{// test for compatible iterator pairif (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 insteadPropertyValues.erase(i);}i = PropertyValues.begin


();}And I am a little puzzled by the code in the above loop... Although Ididn't spend much time trying to grasp the logic here, and I have notbeen playing with C++ iterators too much lately, my experience is that
removing entries from a collection that you're iterating on is usually asure way to shoot yourself in the foot :) so I may be wrong but I sensea 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]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Exception in SDO runtime on Windows, was: [C++] windows build system

2006-09-08 Thread Geoffrey Winn

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
> >::_Const_iterator<1>::_Compat(const
> std::list
> >::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line
> 309 + 0x17 bytesC++
>
>
> tuscany_sdo.dll!std::list
> >::_Const_iterator<1>::operator==(const
> std::list
> >::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line
> 290C++
>  tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
> Line 4564 + 0x37 bytesC++
>  tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
> destructor'()  + 0x2b bytesC++
>  tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef()  Line
> 69 + 0x4c bytesC++
>
>
> 
sdo_test.exe!commonj::sdo::RefCountingPointer::~RefCountingPointer()
> Line 133 + 0x15 bytesC++
>  sdo_test.exe!sdotest::scopetest()  Line 69 + 0x19 bytesC++
>  sdo_test.exe!main(int argc=1, char * * argv=0x00386018)  Line 48 +
> 0x5 bytesC++
>  sdo_test.exe!__tmainCRTStartup()  Line 586 + 0x19 bytesC
>  sdo_test.exe!mainCRTStartup()  Line 403C
>
> 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]
>
>



Re: Exception in SDO runtime on Windows, was: [C++] windows build system

2006-09-07 Thread Geoffrey Winn

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
>::_Const_iterator<1>::_Compat(const
std::list
>::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line
309 + 0x17 bytesC++


tuscany_sdo.dll!std::list
>::_Const_iterator<1>::operator==(const
std::list
>::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line
290C++
 tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()
Line 4564 + 0x37 bytesC++
 tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting
destructor'()  + 0x2b bytesC++
 tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef()  Line
69 + 0x4c bytesC++


sdo_test.exe!commonj::sdo::RefCountingPointer::~RefCountingPointer()
Line 133 + 0x15 bytesC++
 sdo_test.exe!sdotest::scopetest()  Line 69 + 0x19 bytesC++
 sdo_test.exe!main(int argc=1, char * * argv=0x00386018)  Line 48 +
0x5 bytesC++
 sdo_test.exe!__tmainCRTStartup()  Line 586 + 0x19 bytesC
 sdo_test.exe!mainCRTStartup()  Line 403C

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]




Exception in SDO runtime on Windows, was: [C++] windows build system

2006-09-06 Thread Jean-Sebastien Delfino

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 
>::_Const_iterator<1>::_Compat(const 
std::list 
>::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line 
309 + 0x17 bytesC++

tuscany_sdo.dll!std::list 
>::_Const_iterator<1>::operator==(const 
std::list 
>::_Const_iterator<1> & _Right={first=3452816845 second={...} })  Line 
290C++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::~DataObjectImpl()  
Line 4564 + 0x37 bytesC++
tuscany_sdo.dll!commonj::sdo::DataObjectImpl::`scalar deleting 
destructor'()  + 0x2b bytesC++
tuscany_sdo.dll!commonj::sdo::RefCountingObject::releaseRef()  Line 
69 + 0x4c bytesC++

sdo_test.exe!commonj::sdo::RefCountingPointer::~RefCountingPointer()  
Line 133 + 0x15 bytesC++

sdo_test.exe!sdotest::scopetest()  Line 69 + 0x19 bytesC++
sdo_test.exe!main(int argc=1, char * * argv=0x00386018)  Line 48 + 
0x5 bytesC++

sdo_test.exe!__tmainCRTStartup()  Line 586 + 0x19 bytesC
sdo_test.exe!mainCRTStartup()  Line 403C

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]