Re: Exception in SDO runtime on Windows, was: [C++] windows build system
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::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845
second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _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::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
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;
}
Re: Exception in SDO runtime on Windows, was: [C++] windows build system
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
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
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::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _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::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
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
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::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo ::_Const_iterator1::_Compat(conststd::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} })Line309 + 0x17 bytesC++tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo ::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo ::_Const_iterator1 _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::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()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]
Exception in SDO runtime on Windows, was: [C++] windows build system
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::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::_Compat(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _Right={first=3452816845 second={...} }) Line
309 + 0x17 bytesC++
tuscany_sdo.dll!std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1::operator==(const
std::listcommonj::sdo::rdo,std::allocatorcommonj::sdo::rdo
::_Const_iterator1 _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::RefCountingPointercommonj::sdo::DataObject::~RefCountingPointercommonj::sdo::DataObject()
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]
[C++] windows build system
Having just raised a patch to create a VC7 build for BigBank I'm taking a step back and thinking that we need a better position on Windows builds as we have too many variations. In particular I just tried to open the VC7 Calculator sample project and it's not compatible with my oldish verision of VC7. So we are faced with even more varieties of project files. This is not sensible. I have two proposals. 1/ For those who want to use MSVC lets agree a version that we support and try and stick with that. Can I suggest Microsoft Visual C++ 2005 Express Edition. I have to admit that I haven't tried this but I will move if we agree this is the right direction to be going in. Has anyone tried it? 2/ Implement a command line build for windows so that we can automate the build process. I am currently looking at a cygwin build based on the *nix project automake files. I haven't got it working just yet but will report back. Thoughts? Simon
Re: [C++] windows build system
The dependence on MSVC struck me as odd for an open source project when I first saw it but I was reluctant to try to alter something that basically works. I don't think going to the Express Edition helps much since we would still be dependent on a Microsoft product - even if it is free. I think it is better to provide a command line build (as we already do on Linux) as the definitive way to build the product and then anyone who wants to can adapt their favourite IDE to work with that. So I vote for option 2. On 04/09/06, Simon Laws [EMAIL PROTECTED] wrote: Having just raised a patch to create a VC7 build for BigBank I'm taking a step back and thinking that we need a better position on Windows builds as we have too many variations. In particular I just tried to open the VC7 Calculator sample project and it's not compatible with my oldish verision of VC7. So we are faced with even more varieties of project files. This is not sensible. I have two proposals. 1/ For those who want to use MSVC lets agree a version that we support and try and stick with that. Can I suggest Microsoft Visual C++ 2005 Express Edition. I have to admit that I haven't tried this but I will move if we agree this is the right direction to be going in. Has anyone tried it? 2/ Implement a command line build for windows so that we can automate the build process. I am currently looking at a cygwin build based on the *nix project automake files. I haven't got it working just yet but will report back. Thoughts? Simon
Re: [C++] windows build system
The current windows command-line build depends on a copy of MSVC, which users may prefer as it's the official compiler/linker for Windows.. There's also the third option of getting the Eclipse CDT to generate and manage our builds. I have almost no experience with CDT and I've no idea if that pre-reqs MSVC or similar, but I believe Pete and Sebastien have used it. Cheers Andy On 9/4/06, Geoffrey Winn [EMAIL PROTECTED] wrote: The dependence on MSVC struck me as odd for an open source project when I first saw it but I was reluctant to try to alter something that basically works. I don't think going to the Express Edition helps much since we would still be dependent on a Microsoft product - even if it is free. I think it is better to provide a command line build (as we already do on Linux) as the definitive way to build the product and then anyone who wants to can adapt their favourite IDE to work with that. So I vote for option 2. On 04/09/06, Simon Laws [EMAIL PROTECTED] wrote: Having just raised a patch to create a VC7 build for BigBank I'm taking a step back and thinking that we need a better position on Windows builds as we have too many variations. In particular I just tried to open the VC7 Calculator sample project and it's not compatible with my oldish verision of VC7. So we are faced with even more varieties of project files. This is not sensible. I have two proposals. 1/ For those who want to use MSVC lets agree a version that we support and try and stick with that. Can I suggest Microsoft Visual C++ 2005 Express Edition. I have to admit that I haven't tried this but I will move if we agree this is the right direction to be going in. Has anyone tried it? 2/ Implement a command line build for windows so that we can automate the build process. I am currently looking at a cygwin build based on the *nix project automake files. I haven't got it working just yet but will report back. Thoughts? Simon
Re: [C++] windows build system
Simon Laws wrote: Having just raised a patch to create a VC7 build for BigBank I'm taking a step back and thinking that we need a better position on Windows builds as we have too many variations. In particular I just tried to open the VC7 Calculator sample project and it's not compatible with my oldish verision of VC7. So we are faced with even more varieties of project files. This is not sensible. I have two proposals. 1/ For those who want to use MSVC lets agree a version that we support and try and stick with that. Can I suggest Microsoft Visual C++ 2005 Express Edition. I have to admit that I haven't tried this but I will move if we agree this is the right direction to be going in. Has anyone tried it? Good idea, too many versions on Windows are getting difficult to manage. I think we should pick a single version, the free Visual C++ 2005 Express as you suggest. I also agree with Andy's comment later in this thread that most users will want Visual Studio on Windows. Apache Httpd and Axis2C only document how to build with Visual Studio as far as I can see. Stdcxx supports Visual Studio as well. 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 :) 2/ Implement a command line build for windows so that we can automate the build process. I am currently looking at a cygwin build based on the *nix project automake files. I haven't got it working just yet but will report back. It will be interesting to see if we can make our automake based build portable. It would be great if we could generate the Visual C++ solution from that automake build... but I'm not sure if that's easy to do or even possible. If we can use our automake build with few or no changes then we should consider this, but IMO we need the Visual C++ 2005 express build as well (handcrafted or generated). Thoughts? Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
