-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, December 05, 2003 5:44 AM To: [EMAIL PROTECTED] Subject: [ace-bugs] Digest Number 958
------------------------ Yahoo! Groups Sponsor ---------------------~--> KnowledgeStorm has over 22,000 B2B technology solutions. The most comprehensive IT buyers' information available. Research, compare, decide. E-Commerce | Application Dev | Accounting-Finance | Healthcare | Project Mgt | Sales-Marketing | More http://us.click.yahoo.com/IMai8D/UYQGAA/cIoLAA/r9ewlB/TM ---------------------------------------------------------------------~-> There are 12 messages in this issue. Topics in this digest: 1. Bug? in ACE_Connector::connect_i From: Kobi Cohen-Arazi <[EMAIL PROTECTED]> 2. Re: [ace-users] Bug? in ACE_Connector::connect_i From: Kobi Cohen-Arazi <[EMAIL PROTECTED]> 3. Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: Thomas Lockhart <[EMAIL PROTECTED]> 4. RE: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: "Johnny Willemsen" <[EMAIL PROTECTED]> 5. Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: Thomas Lockhart <[EMAIL PROTECTED]> 6. Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: Thomas Lockhart <[EMAIL PROTECTED]> 7. RE: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: "Johnny Willemsen" <[EMAIL PROTECTED]> 8. Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: Thomas Lockhart <[EMAIL PROTECTED]> 9. Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: Thomas Lockhart <[EMAIL PROTECTED]> 10. Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: Thomas Lockhart <[EMAIL PROTECTED]> 11. RE: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: "Johnny Willemsen" <[EMAIL PROTECTED]> 12. Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ From: Thomas Lockhart <[EMAIL PROTECTED]> ________________________________________________________________________ ________________________________________________________________________ Message: 1 Date: Thu, 04 Dec 2003 17:18:58 +0200 From: Kobi Cohen-Arazi <[EMAIL PROTECTED]> Subject: Bug? in ACE_Connector::connect_i Hi All, ACE VERSION: 5.3.3 HOST MACHINE and OPERATING SYSTEM: Win2k sp4 server. Winsock2 5.0.2195.6601 COMPILER NAME AND VERSION (AND PATCHLEVEL): .NET 7.1 (2003) CONTENTS OF $ACE_ROOT/ace/config.h: #include "config-win32.h" AREA/CLASS/EXAMPLE AFFECTED: ACE_Connector::connect_i DOES THE PROBLEM AFFECT: EXECUTION? Yes, The following seems to be incorrect: .... if (result == -1) { if (use_reactor && errno == EWOULDBLOCK) { .... Checkin against errno and not against ACE_OS::last_error() is buggy. I am using ACE_Synch_Options::async, and ::connect() returns -1 with EWORULDBLOCK. However on win32 errno == 0. The soultion will be checking against ACE_OS::last_error() which is very important to do so on win32 platforms. Thanks, Kobi. ________________________________________________________________________ ________________________________________________________________________ Message: 2 Date: Thu, 04 Dec 2003 18:23:36 +0200 From: Kobi Cohen-Arazi <[EMAIL PROTECTED]> Subject: Re: [ace-users] Bug? in ACE_Connector::connect_i Hi Steve, Yes, I've changed errno to ACE_OS::last_error(). And it worked . The strange thing was in that point ACE_OS::last_error() == 10035 and errno == 0 (I've added ACE_DEBUG to that point to verify that), and the server side doing the accept call - succeeded. PS. Maybe we need to swap the rest of the code so more cases like that won't happen ? Thanks, Kobi. Steve Huston wrote: > Hi Kobi, > > Did you try this fix on your system? If not, please do and let us know > how it works. > > Thanks, > > -Steve > > -- > Steve Huston, Riverace Corporation > Co-author of "C++ Network Programming" and "The ACE Programmer's > Guide" > Books, ACE kit and support info at http://www.riverace.com/ > > >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of Kobi Cohen-Arazi >>Sent: Thursday, December 04, 2003 10:19 AM >>To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >>Subject: [ace-users] Bug? in ACE_Connector::connect_i >> >> >>Hi All, >> >> ACE VERSION: 5.3.3 >> >> HOST MACHINE and OPERATING SYSTEM: >> Win2k sp4 server. >> Winsock2 5.0.2195.6601 >> >> COMPILER NAME AND VERSION (AND PATCHLEVEL): >> .NET 7.1 (2003) >> >> CONTENTS OF $ACE_ROOT/ace/config.h: >> #include "config-win32.h" >> >> >> AREA/CLASS/EXAMPLE AFFECTED: >> ACE_Connector::connect_i >> >> DOES THE PROBLEM AFFECT: >> EXECUTION? >> Yes, The following seems to be incorrect: >> .... >> if (result == -1) >> { >> if (use_reactor && errno == EWOULDBLOCK) >> { >> .... >> Checkin against errno and not against >>ACE_OS::last_error() is buggy. >> >> I am using ACE_Synch_Options::async, and ::connect() returns > > -1 > >> with EWORULDBLOCK. However on win32 errno == 0. >> >> The soultion will be checking against >>ACE_OS::last_error() which is >>very important to do so on win32 platforms. >> >>Thanks, >>Kobi. >> > > > > > ________________________________________________________________________ ________________________________________________________________________ Message: 3 Date: Thu, 04 Dec 2003 08:42:24 -0800 From: Thomas Lockhart <[EMAIL PROTECTED]> Subject: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > > ># if defined (ACE_VXWORKS) && ACE_VXWORKS == 0x542 ># define ACE_LACKS_CLEARERR ># endif /* ACE_VXWORKS == 0x542 */ >Would that do the trick, maybe the 542 version is broken? > > It would do the trick, but I'm not sure that 542 is broken. I think that corresponds to Tornado 2.0.2, which we have been using in production with tao 1.2.1 for over a year. And for that version of tao ACE_LACKS_CLEARERR was not defined. Hmm, maybe because clearerr() was not used. I'm searching through google and finding that: o in April Olli Savia reported a problem with clearerr defined as a macro in LynxOS (it is a macro also in VxWorks). The fix was to #undef clearerr. But the compiler was gcc-2.7.x, which is no longer supported in tao due to C++ namespace support. o There is some hint that clearerr defined as a macro by the OS is A Bad Thing. This is the case for VxWorks, but does not seem to hurt compilation. Comments? I think maybe I was not subscribed to ace-bugs where the discussions took place. I am now though... - Tom ________________________________________________________________________ ________________________________________________________________________ Message: 4 Date: Thu, 4 Dec 2003 17:48:28 +0100 From: "Johnny Willemsen" <[EMAIL PROTECTED]> Subject: RE: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ Hi, Then I will change it to == 0x542. That way it works with Tornado 2.2 and with older versions. 0x540 is not supported anymore, maybe we should add a check in the config file to make sure that people who try it will get a clear error. Johnny -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Lockhart Sent: donderdag 4 december 2003 17:42 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [ace-bugs] Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > > ># if defined (ACE_VXWORKS) && ACE_VXWORKS == 0x542 ># define ACE_LACKS_CLEARERR ># endif /* ACE_VXWORKS == 0x542 */ >Would that do the trick, maybe the 542 version is broken? > > It would do the trick, but I'm not sure that 542 is broken. I think that corresponds to Tornado 2.0.2, which we have been using in production with tao 1.2.1 for over a year. And for that version of tao ACE_LACKS_CLEARERR was not defined. Hmm, maybe because clearerr() was not used. I'm searching through google and finding that: o in April Olli Savia reported a problem with clearerr defined as a macro in LynxOS (it is a macro also in VxWorks). The fix was to #undef clearerr. But the compiler was gcc-2.7.x, which is no longer supported in tao due to C++ namespace support. o There is some hint that clearerr defined as a macro by the OS is A Bad Thing. This is the case for VxWorks, but does not seem to hurt compilation. Comments? I think maybe I was not subscribed to ace-bugs where the discussions took place. I am now though... - Tom ________________________________________________________________________ ________________________________________________________________________ Message: 5 Date: Thu, 04 Dec 2003 09:28:12 -0800 From: Thomas Lockhart <[EMAIL PROTECTED]> Subject: Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > > >Then I will change it to == 0x542. That way it works with Tornado 2.2 and >with older versions. 0x540 is not supported anymore, maybe we should add a >check in the config file to make sure that people who try it will get a >clear error. > > OK. I'm rummaging through the cvsweb diffs to try to figure out the history on this issue, and will send another email soon with a summary as I understand it. But I'm guessing that the definition of ACE_LACKS_CLEARERR does not need to be there at all for VxWorks, since there seems to have been subsequent changes to OS.h to handle the general clearerr-as-macro situation. I should have an opinion (??) in a bit, and will be testing over the next few days. - Tom ________________________________________________________________________ ________________________________________________________________________ Message: 6 Date: Thu, 04 Dec 2003 09:38:06 -0800 From: Thomas Lockhart <[EMAIL PROTECTED]> Subject: Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > > >Then I will change it to == 0x542. That way it works with Tornado 2.2 and >with older versions. 0x540 is not supported anymore, maybe we should add a >check in the config file to make sure that people who try it will get a >clear error. > > Oh, on the VxWorks/Tornado versioning: o VxWorks 0x55* corresponds to the Tornado 2.2 series, shipped with something resembling gcc-2.96. o VxWorks 0x54* corresponds to the Tornado 2.0 series, shipped with 2.7.x claiming "egcs patches". That entire series (and earlier) is no longer supported by TAO afaict due to namespace troubles. It has exception troubles too, but using non-native exceptions should be OK for that part. o I'm not sure how the Tornado 2.1 series was labeled wrt VxWorks, since it did not make it into general release and we never got our hands on a copy (the reps said it was too buggy on non-Altivec processors to bother with). - Tom ________________________________________________________________________ ________________________________________________________________________ Message: 7 Date: Thu, 4 Dec 2003 18:40:36 +0100 From: "Johnny Willemsen" <[EMAIL PROTECTED]> Subject: RE: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ Hi, When I remember correctly there has been a 0x542 release for some platforms that shipped with gcc-2.96. Only 0x540 is VxWorks 5.4 and is shipped with 2.7.x which we don't support anymore. Johnny -----Original Message----- From: Thomas Lockhart [mailto:[EMAIL PROTECTED] Sent: donderdag 4 december 2003 18:38 To: Johnny Willemsen Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [ace-bugs] Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > > >Then I will change it to == 0x542. That way it works with Tornado 2.2 >and with older versions. 0x540 is not supported anymore, maybe we >should add a check in the config file to make sure that people who try >it will get a clear error. > > Oh, on the VxWorks/Tornado versioning: o VxWorks 0x55* corresponds to the Tornado 2.2 series, shipped with something resembling gcc-2.96. o VxWorks 0x54* corresponds to the Tornado 2.0 series, shipped with 2.7.x claiming "egcs patches". That entire series (and earlier) is no longer supported by TAO afaict due to namespace troubles. It has exception troubles too, but using non-native exceptions should be OK for that part. o I'm not sure how the Tornado 2.1 series was labeled wrt VxWorks, since it did not make it into general release and we never got our hands on a copy (the reps said it was too buggy on non-Altivec processors to bother with). - Tom ________________________________________________________________________ ________________________________________________________________________ Message: 8 Date: Thu, 04 Dec 2003 10:44:20 -0800 From: Thomas Lockhart <[EMAIL PROTECTED]> Subject: Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > > >When I remember correctly there has been a 0x542 release for some platforms >that shipped with gcc-2.96. Only 0x540 is VxWorks 5.4 and is shipped with >2.7.x which we don't support anymore. > > Well, Wind River isn't helping us much by having that mysterious 2.1 series, but here is what I see in my installations. They presumably have some patches applied (per WRS tradition, we sometimes only find out about available patches if we have a problem, so the patching is probably minimal). From our Tornado 2.0 installation (in target/h/version.h): #define VXWORKS_VERSION "5.4" g++ppc --version cygnus-2.7.2-960126 egcs-971225 tornado 2.0 From our Tornado 2.0.2 installation (still the 2.7.x/egcs compiler): #define VXWORKS_VERSION "5.4.2" g++ppc --version cygnus-2.7.2-960126 egcs-971225 tornado 2.0 From our Tornado 2.2 installation (!! note bump in version convention): #define RUNTIME_NAME "VxWorks" #define RUNTIME_VERSION "5.5.1" #define VXWORKS_VERSION RUNTIME_NAME RUNTIME_VERSION g++ppc --version gcc-2.96 From our Tornado 2.2.1 installation: #define RUNTIME_NAME "VxWorks" #define RUNTIME_VERSION "5.5.1" #define VXWORKS_VERSION RUNTIME_NAME RUNTIME_VERSION g++ppc --version gcc-2.96 The gap I have is with the conventions for Tornado 2.1.x. I'm guessing that it may claim to be "5.5" and has a compiler claiming to be some rev of 2.96. Does anyone have something they could look at? - Tom >Oh, on the VxWorks/Tornado versioning: >o VxWorks 0x55* corresponds to the Tornado 2.2 series, shipped with >something resembling gcc-2.96. >o VxWorks 0x54* corresponds to the Tornado 2.0 series, shipped with 2.7.x >claiming "egcs patches". That entire series (and earlier) is no longer >supported by TAO afaict due to namespace troubles. It has exception troubles >too, but using non-native exceptions should be OK for that part. >o I'm not sure how the Tornado 2.1 series was labeled wrt VxWorks, since it >did not make it into general release and we never got our hands on a copy >(the reps said it was too buggy on non-Altivec processors to bother with). > > ________________________________________________________________________ ________________________________________________________________________ Message: 9 Date: Thu, 04 Dec 2003 11:00:44 -0800 From: Thomas Lockhart <[EMAIL PROTECTED]> Subject: Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > > >> When I remember correctly there has been a 0x542 release for some >> platforms >> that shipped with gcc-2.96. Only 0x540 is VxWorks 5.4 and is shipped >> with >> 2.7.x which we don't support anymore. >> The gap I have is with the conventions for Tornado 2.1.x. I'm >> guessing that it > >> may claim to be "5.5" and has a compiler claiming to be some rev of 2.96. > It may be that the versioning for Tornado 2.1.x combines VxWorks 5.4.2 with an unfortunate pre-release of gcc-2.96, which would jibe with your recollection. In which case we would have to start looking at the CC_VERSION derived in the platform*.GNU area to distinguish all combinations. otoh, we all agree that tao no longer supports the 2.0 series. So we could use 542 to indicate the 2.1 series (pending confirmation of versioning for that aborted release). You have probably been saying this all along, but I was stuck on the conflict with info for the 2.0 series. btw, I've been going through and updating some of the platform*.GNU and config*.h information for VxWorks to fix up other areas, including the potential use of native exceptions (we have backed off from actually using native exceptions on VxWorks for now due to memory footprint concerns). Will send patches... - Tom ________________________________________________________________________ ________________________________________________________________________ Message: 10 Date: Thu, 04 Dec 2003 11:03:25 -0800 From: Thomas Lockhart <[EMAIL PROTECTED]> Subject: Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > o There is some hint that clearerr defined as a macro by the OS is A > Bad Thing. This is the case for VxWorks, but does not seem to hurt > compilation. Comments? I see that there is some code in or around OS.h intended to handle the clearerr-as-macro case which was modified after first use of ACE_LACKS_CLEARERR with VxWorks. So perhaps the issue is moot for at least the most recent releases of TAO and VxWorks. - Tom ________________________________________________________________________ ________________________________________________________________________ Message: 11 Date: Thu, 4 Dec 2003 18:23:29 +0100 From: "Johnny Willemsen" <[EMAIL PROTECTED]> Subject: RE: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ Hi, Thanks for the info. I will have a look in detail tomorrow. I would propose to use ACE_VXWORKS as the define to check on the right version. 0x540 is then Tornado 2.0 with gcc 2.7.2, 0x542 is Tornado 2.1 (or whatever windriver called it) but is has gcc 2.9.6 and 0x550 is VxWorks 5.5, I only don't know what VxWorks AE is then? Johnny > -----Original Message----- > From: Thomas Lockhart [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 04, 2003 7:44 PM > To: Johnny Willemsen > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [ace-bugs] Re: ACE_LACKS_CLEARERR for Tornado > 2.2.x and g++ > > > > > > >When I remember correctly there has been a 0x542 release for > some platforms > >that shipped with gcc-2.96. Only 0x540 is VxWorks 5.4 and is > shipped with > >2.7.x which we don't support anymore. > > > > > Well, Wind River isn't helping us much by having that mysterious 2.1 > series, but here is what I see in my installations. They > presumably have > some patches applied (per WRS tradition, we sometimes only find out > about available patches if we have a problem, so the patching is > probably minimal). > > From our Tornado 2.0 installation (in target/h/version.h): > #define VXWORKS_VERSION "5.4" > g++ppc --version > cygnus-2.7.2-960126 egcs-971225 tornado 2.0 > > From our Tornado 2.0.2 installation (still the 2.7.x/egcs compiler): > #define VXWORKS_VERSION "5.4.2" > g++ppc --version > cygnus-2.7.2-960126 egcs-971225 tornado 2.0 > > From our Tornado 2.2 installation (!! note bump in version > convention): > #define RUNTIME_NAME "VxWorks" > #define RUNTIME_VERSION "5.5.1" > #define VXWORKS_VERSION RUNTIME_NAME RUNTIME_VERSION > g++ppc --version > gcc-2.96 > > From our Tornado 2.2.1 installation: > #define RUNTIME_NAME "VxWorks" > #define RUNTIME_VERSION "5.5.1" > #define VXWORKS_VERSION RUNTIME_NAME RUNTIME_VERSION > g++ppc --version > gcc-2.96 > > The gap I have is with the conventions for Tornado 2.1.x. I'm > guessing > that it may claim to be "5.5" and has a compiler claiming to > be some rev > of 2.96. Does anyone have something they could look at? > > - Tom > > >Oh, on the VxWorks/Tornado versioning: > >o VxWorks 0x55* corresponds to the Tornado 2.2 series, shipped with > >something resembling gcc-2.96. > >o VxWorks 0x54* corresponds to the Tornado 2.0 series, > shipped with 2.7.x > >claiming "egcs patches". That entire series (and earlier) is > no longer > >supported by TAO afaict due to namespace troubles. It has > exception troubles > >too, but using non-native exceptions should be OK for that part. > >o I'm not sure how the Tornado 2.1 series was labeled wrt > VxWorks, since it > >did not make it into general release and we never got our > hands on a copy > >(the reps said it was too buggy on non-Altivec processors to > bother with). > > > > > > ________________________________________________________________________ ________________________________________________________________________ Message: 12 Date: Thu, 04 Dec 2003 11:47:24 -0800 From: Thomas Lockhart <[EMAIL PROTECTED]> Subject: Re: Re: ACE_LACKS_CLEARERR for Tornado 2.2.x and g++ > > >Thanks for the info. I will have a look in detail tomorrow. I would propose >to use ACE_VXWORKS as the define to check on the right version. 0x540 is >then Tornado 2.0 with gcc 2.7.2, 0x542 is Tornado 2.1 (or whatever windriver >called it) but is has gcc 2.9.6 and 0x550 is VxWorks 5.5, I only don't know >what VxWorks AE is then? > > OK, though I would like to really confirm that Tornado 2.1.x shipped with a VxWorks claiming to be 5.4.2, since Tornado 2.0.2 shipped with the same ^%&* VxWorks version number. In any case, let's get some comments at the top of the platform support file so we don't have to think this through again :/ I don't know about AE, though I could look around and see if I can find anyone using it. - Tom ________________________________________________________________________ ________________________________________________________________________ Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
