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

[Douglas C. Schmidt]

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 ]
>>