[tao-users] [EXTERNAL] Re: TAO 1.7.4 (I know, its old)

Johnny Willemsen jwillemsen at remedy.nl
Thu Apr 2 01:47:23 CDT 2020


Hi,

This code is ancient, see
https://github.com/DOCGroup/ACE_TAO/blob/e72631e439c349d12ac37d115b5fe2271838ac22/ACE/ace/OS_NS_sys_socket.cpp#L38
for the current code, there this is handled through the
ACE_SOCKCALL_RETURN macro.

Rob, you very likely get much more issues than just this one. In our
experience it is in the end faster and more effective to upgrade to a
newer ACE than to try to patch such an ancient version.

Best regards,

Johnny Willemsen
Remedy IT
http://www.remedy.nl

On 4/1/20 11:19 PM, Douglas C. Schmidt wrote:
> Hi Rob,
> 
>    We appreciate you tracking this down!  That's definitely an
> oversight that we need to fix.  Johnny/Steve, is there a better way to
> fix this than what Rob did below?
> 
>    Thanks,
>    
>         Doug
> 
>> So I finally got the debugger working properly and found the problem, or at=
>> least a hack workaround.  In ACE_wrappers\ace\OS_NS_sys_socket.inl, I had =
>> to modify the connect operation.  It seems errno was not getting set proper=
>> ly for some reason.  I copied the operation below.  Any suggestions for a b=
>> etter fix or go with this?
>>
>> Thanks,
>> Rob
>>
>>
>> ACE_INLINE int
>> ACE_OS::connect (ACE_HANDLE handle,
>>                 struct sockaddr *addr,
>>                 int addrlen)
>> {
>>  ACE_OS_TRACE ("ACE_OS::connect");
>> #if defined (ACE_LACKS_CONNECT)
>>  ACE_UNUSED_ARG (handle);
>>  ACE_UNUSED_ARG (addr);
>>  ACE_UNUSED_ARG (addrlen);
>>  ACE_NOTSUP_RETURN (-1);
>> #else
>>
>> //  NEW CODE
>>  int ret =3D ::connect((ACE_SOCKET)handle,
>>      addr,
>>      (ACE_SOCKET_LEN)addrlen);
>>  if (ret =3D=3D -1) {
>>
>>      if (WSAGetLastError() =3D=3D WSAEWOULDBLOCK) {
>>          errno =3D EWOULDBLOCK;
>>      }
>>  }
>>  return ret;
>> // END NEW CODE, BEGIN OLD CODE
>> //  ACE_SOCKCALL_RETURN (::connect ((ACE_SOCKET) handle,
>> //                                  addr,
>> //                                  (ACE_SOCKET_LEN) addrlen), int, -1);
>> #endif /* ACE_LACKS_CONNECT */
>> }
>>
>>
>> ________________________________________
>> From: Johnny Willemsen <jwillemsen at remedy.nl>
>> Sent: Tuesday, March 31, 2020 10:44 AM
>> To: Ruff, Rob; tao-users
>> Subject: [EXTERNAL] Re: TAO 1.7.4 (I know, its old)
>>
>> This email originated from outside of SRC. Do not click links or open attac=
>> hments unless you recognize the sender and know the content is safe.
>>
>>
>>
>>
>> Hi,
>>
>> Thanks for using the PRF form, yes, 1.7.4 is really ancient. Would
>> recommend you to enable TAO logging and see what for logging you get.
>>
>> A lot of things changed between 1.7.4 and now, sorting out what changed
>> will be a huge task also.
>>
>> Best regards,
>>
>> Johnny Willemsen
>> Remedy IT
>> http://www.remedy.nl
>>
>> On 3/31/20 4:38 PM, Ruff, Rob wrote:
>>>
>>>
>>> To: tao-bugs at cs.wustl.edu
>>> Subject: TAO: Exceptions accessing Naming Service with VS 2019 upgrade
>>>
>>>     ACE VERSION: 5.7.4
>>>     TAO VERSION: 1.7.4
>>>
>>>     HOST MACHINE and OPERATING SYSTEM: Dell Precision M4800, Windows 10
>>>         If on Windows based OS's, which version of WINSOCK do you
>>>         use?:
>>>
>>>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>>>     COMPILER NAME AND VERSION (AND PATCHLEVEL):MS VS 2008 sp1, MS VS 2019
>>>
>>>     THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
>>>     specific file, simply state which one]: config-win32.h
>>>
>>>     THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
>>>     use a link to a platform-specific file, simply state which one
>>>     (unless this isn't used in this case, e.g., with Microsoft Visual
>>>     C++)]:
>>>
>>>     BUILD METHOD USED:
>>> [Experimental ./configure or traditional makefile/project file?]
>>>
>>>     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
>>>     (used by MPC when you generate your own makefiles):
>>>
>>>     AREA/CLASS/EXAMPLE AFFECTED:
>>> [What example failed?  What module failed to compile?]
>>> Naming service access runtime issue
>>>
>>>     DOES THE PROBLEM AFFECT:
>>>         COMPILATION? NO
>>>         LINKING? NO
>>>             On Unix systems, did you run make realclean first?
>>>         EXECUTION? YES
>>>         OTHER (please specify)?
>>> [Please indicate whether ACE/TAO, your application, or both are affected.=
>> ]
>>> Both
>>>
>>>     SYNOPSIS:
>>> Trying to migrate from VS 2008 to VS 2019
>>>
>>>     DESCRIPTION:
>>> I let VS 2019 auto update the ace/TAO VS 2008 files.  With a few minor ch=
>> anges,
>>> I was able to compile and build everything.  I can start applications but=
>> none
>>> can communicate with the naming service.  I always get a CORBA TRANSIENT
>>> exception.
>>>
>>> I ran tao_nslist from the debugger and it throws the exception on:
>>>
>>> CosNaming::NamingContext_var root_nc =3D
>>>     CosNaming::NamingContext::_narrow (obj.in ());
>>>
>>> Any tips on what could be wrong?
>>>
>>> I built the latest ace/tao with vs 2019 and was able to connect tao_nslis=
>> t to
>>> the naming service but that upgrade would result in quite a few changes t=
>> o our
>>> code so I was hoping to stick with 5.7.4 if possible.  The software is fo=
>> r
>>> command and control of three communication systems in operation in Antarc=
>> tica.
>>>
>>>
>>>     REPEAT BY:
>>> As a simple test, I used naming_service and tao_nslist applications built=
>> with
>>> both VS 2008 and VS 2019.  Here are the results:
>>>
>>> connect VS 2008 tao_nslist to VS 2008 naming_service - WORKS
>>> connect VS 2019 tao_nslist to VS 2008 naming_service - TRANSIENT exceptio=
>> n
>>> connect VS 2008 tao_nslist to VS 2019 naming_service - WORKS
>>> connect VS 2019 tao_nslist to VS 2019 naming_service - TRANSIENT exceptio=
>> n
>>>
>>>     SAMPLE FIX/WORKAROUND:
>>> [If available ]
>>>
>>> ________________________________
>>>
>>> CONFIDENTIALITY NOTICE: This email constitutes an electronic communicatio=
>> n within the meaning of the Electronic Communications Privacy Act, 18 U.S.C=
>> . 2510, and its disclosure is strictly limited to the named recipient(s) in=
>> tended by the sender of this message. This email, and any attachments, may =
>> contain confidential and/or proprietary information of Scientific Research =
>> Corporation. If you are not a named recipient, any copying, using, disclosi=
>> ng or distributing to others the information in this email and attachments =
>> is STRICTLY PROHIBITED. If you have received this email in error, please no=
>> tify the sender immediately and permanently delete the email, any attachmen=
>> ts, and all copies thereof from any drives or storage media and destroy any=
>> printouts or hard copies of the email and attachments.
>>>
>>> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain tech=
>> nical data subject to U.S export restrictions under the International Traff=
>> ic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR=
>> ). Export or transfer of this technical data and/or related information to =
>> any foreign person(s) or entity(ies), either within the U.S. or outside of =
>> the U.S., may require advance export authorization by the appropriate U.S. =
>> Government agency prior to export or transfer. In addition, technical data =
>> may not be exported or transferred to certain countries or specified design=
>> ated nationals identified by U.S. embargo controls without prior export aut=
>> horization. By accepting this email and any attachments, all recipients con=
>> firm that they understand and will comply with all applicable ITAR, EAR and=
>> embargo compliance requirements.
>>>
>>
>> ________________________________
>>
>> CONFIDENTIALITY NOTICE: This email constitutes an electronic communication =
>> within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. =
>> 2510, and its disclosure is strictly limited to the named recipient(s) inte=
>> nded by the sender of this message. This email, and any attachments, may co=
>> ntain confidential and/or proprietary information of Scientific Research Co=
>> rporation. If you are not a named recipient, any copying, using, disclosing=
>> or distributing to others the information in this email and attachments is=
>> STRICTLY PROHIBITED. If you have received this email in error, please noti=
>> fy the sender immediately and permanently delete the email, any attachments=
>> , and all copies thereof from any drives or storage media and destroy any p=
>> rintouts or hard copies of the email and attachments.
>>
>> EXPORT COMPLIANCE NOTICE: This email and any attachments may contain techni=
>> cal data subject to U.S export restrictions under the International Traffic=
>> in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).=
>> Export or transfer of this technical data and/or related information to an=
>> y foreign person(s) or entity(ies), either within the U.S. or outside of th=
>> e U.S., may require advance export authorization by the appropriate U.S. Go=
>> vernment agency prior to export or transfer. In addition, technical data ma=
>> y not be exported or transferred to certain countries or specified designat=
>> ed nationals identified by U.S. embargo controls without prior export autho=
>> rization. By accepting this email and any attachments, all recipients confi=
>> rm that they understand and will comply with all applicable ITAR, EAR and e=
>> mbargo compliance requirements.
>>
> 
> 


More information about the tao-users mailing list