[ace-users] parse_svcconf_args_i() fails in TAO_Internal
Vial, Florent
Hi everyone,
i am using ACE/TAO 5.6.7/1.6.7 at patch level 3 from http://www.theaceorb.com/.
Here is my PROBLEM-REPORT-FORM, thank you in advance for the help.
ACE VERSION: 5.6a_p3
HOST MACHINE and OPERATING SYSTEM: Windows 7 ultimate 64 bit
TARGET MACHINE and OPERATING SYSTEM, if different from HOST: NamingServer runnning on RHEL 4.6 64 bit
COMPILER NAME AND VERSION (AND PATCHLEVEL): MSVC 9 (Visual Studio 2008 SP1)
CONTENTS OF $ACE_ROOT/ace/config.h : #include "ace/config-win32.h"
CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU : NONE
CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features: NONE
LEVEL OF URGENCY (LOW, MEDIUM, or HIGH): MEDIUM
AREA/CLASS/EXAMPLE AFFECTED: parse_svcconf_args_i in TAO_Internal.cpp because of ACE_Arg_Shifter.
DOES THE PROBLEM AFFECT: COMPILATION? NO
LINKING? NO
EXECUTION? YES
My application won't start as it did before with ACE/TAO 5.5.6/1.5.6
SYNOPSIS:
The arg parsing seems to be flawed.
ACE_TCHAR is char since ACE_USES_WCHAR was not defined when compiling (tried with ACE_USES_WCHAR but did not help further).
UNICODE and _UNICODE were defined when compiling ACE+TAO.
DESCRIPTION:
The TAO client application starts under Windows 7 Ultimate 64 bit, and tries to connect to the TAO server located on machine AAA.BBB.CCC.DDD
which runs a Naming_Service on port 1055.
Client code is following
CORBA::ORB_var mOrb = CORBA::ORB_init(ls_argc, ls_argv, "");
with ls_argc = 4
ls_argv[0] = "ClientName"
ls_argv[1] = "-ORBInitRef NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService"
ls_argv[2] = "-ORBDottedDecimalAddresses 1"
ls_argv[3] = "-ORBSvcConf ClientName.ORB.conf"
The content of the ClientName.ORB.conf is not stated here as it is irrelevant: the file won't get read at all.
The file is located in the same directory as the one where the executable is launched.
ORB_init calls TAO::ORB::open_global_services() with ls_arc and ls_argv (ORB.cpp line 1257).
Debug output is following (tao_debug_level = 5):
TAO (3404|3700) Initializing the process-wide service context
Ignoring unknown argument 'ClientName'
Ignoring unknown argument '-ORBInitRef NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService'
Ignoring unknown argument '-ORBDottedDecimalAddresses 1'
Ignoring unknown argument '-ORBSvcConf ClientName.ORB.conf'
Then TAO::ORB::open_services (oc->configuration (), command_line.get_argc (), command_line.get_TCHAR_argv ()); gets called (ORB.cpp line 1323).
Debug output is following (tao_debug_level = 5):
TAO (2856|4676) Completed initializing the process-wide service context
TAO (2856|4676) Default ORB services initialization begins
TAO (2856|4676) Default ORB services initialization completed
TAO (2856|4676) We are the default ORB ...
TAO (2856|4676) Initializing the orb-specific services
Ignoring unknown argument 'ClientName'
Ignoring unknown argument '-ORBInitRef NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService'
Ignoring unknown argument '-ORBDottedDecimalAddresses 1'
Ignoring unknown argument '-ORBSvcConf ClientName.ORB.conf'
Thre ORB Core instance initialization is done in oc->init (command_line.get_argc(), command_line.get_ASCII_argv()); (ORB.cpp line 1357)
In ORB_Core.cpp line 1124, ouput shows
ERROR: Unknown "-ORB" option <-ORBSvcConf Marvin.ORB.conf>
an exception is thrown (by the way, I think "Unknown "-ORB" option <-ORBSvcConf ClientName.ORB.conf>" would be a better error to throw than
"system exception, ID 'IDL:omg.org/CORBA/BAD_PARAM:1.0' TAO exception, minor code = 11 (ORB Core initialization failed; EINVAL), completed = NO").
and ORB gets shut down.
It seems that parse_svcconf_args_i() does not do its job properly (TAO_Internal.cpp line 732).
The line 743 is IMHO suspicious: if (arg_shifter.cur_arg_strncasecmp (ACE_TEXT ("-ORBSvcConf")) == 0)
Indeed, when the argument "-ORBSvcConf ClientName.ORB.conf" gets parsed,
ACE_Arg_Shifter_T<CHAR_TYPE>::cur_arg_strncasecmp("-ORBSvcConf") is called
and ACE_OS::strncasecmp("-ORBSvcConf ClientName.ORB.conf",
"-ORBSvcConf",11) returns 0 as expected.
(in my setup, ACE_OS::strncasecmp -> ACE_STRNCASECMP_EQUIVALENT -> _strnicmp (MSVC9).)
Then, ACE_OS::strlen("-ORBSvcConf ClientName.ORB.conf") returns 31, that is the total length of the string.
Of course, 31 != 11, so the function returns remaining = 12 ("// matches, with more info to boot!").
Coming back to parse_svcconf_args_i(), the test if (arg_shifter.cur_arg_strncasecmp (ACE_TEXT ("-ORBSvcConf")) == 0) ist not validated, although it should be (12 > 0).
The consequence is that the argument is not consumed by the Arg_Shifter, adn when TAO_ORB_Core::init is called,
'-ORBInitRef NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService' and '-ORBDottedDecimalAddresses 1' gets handled properly, but '-ORBSvcConf ClientName.ORB.conf' lands in the test (arg_shifter.cur_arg_strncasecmp (ACE_TEXT("-ORB")) != -1) at line 1124.
Once again, this test fails since the function returns a value > 0 indicatin matching + extra info.
The result is that the exception at line 1136 is thrown.
REPEAT BY:
SAMPLE FIX/WORKAROUND:
Replace line 743 in TAO_Internal.cpp from
if (arg_shifter.cur_arg_strncasecmp (ACE_TEXT ("-ORBSvcConf")) == 0)
to
if (arg_shifter.cur_arg_strncasecmp (ACE_TEXT ("-ORBSvcConf")) >= 0)
JOIN US FOR THE JOURNEY… View Our New Digital Cameras: http://www.arridigital.com
Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: HRA 57918
Persönlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: München - Registergericht: Amtsgericht München - Handelsregisternummer: HRB 54477
Geschäftsführer: Franz Kraus; Dr. Martin Prillmann
Johnny Willemsen
Hi,
For any problems related to the OCI distribution contact OCI. I would recommend you to download x.7.4 from http://download.dre.vanderbilt.edu
Johnny
Simon Massey
with ls_argc = 4
ls_argv[0] = "ClientName"
ls_argv[1] = "-ORBInitRef
NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService"
ls_argv[2] = "-ORBDottedDecimalAddresses 1"
ls_argv[3] = "-ORBSvcConf ClientName.ORB.conf"
This is incorrect. You actually have 7 args and these should be:
with ls_argc = 7
ls_argv[0] = "ClientName"
ls_argv[1] = "-ORBInitRef"
ls_argv[2] = "NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService"
ls_argv[3] = "-ORBDottedDecimalAddresses"
ls_argv[4] = "1"
ls_argv[5] = "-ORBSvcConf"
ls_argv[6] = "ClientName.ORB.conf"
Hi,
Johnny
Hi everyone,
ACE VERSION: 5.6a_p3
CONTENTS OF $ACE_ROOT/include/makeinclude/platform_macros.GNU : NONE
CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features: NONE
LINKING? NO
EXECUTION? YES
SYNOPSIS:
DESCRIPTION:
Client code is following
with ls_argc = 4
ls_argv[0] = "ClientName"
Ignoring unknown argument 'ClientName'
Ignoring unknown argument 'ClientName'
REPEAT BY:
SAMPLE FIX/WORKAROUND:
http://www.arridigital.com <http://www.arridigital.com/>
Douglas C. Schmidt
hi Folks,
> You state that you are using:
> with ls_argc = 4
> ls_argv[0] = "ClientName"
> ls_argv[1] = "-ORBInitRef
> NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService"
> ls_argv[2] = "-ORBDottedDecimalAddresses 1"
> ls_argv[3] = "-ORBSvcConf ClientName.ORB.conf"
>
> This is incorrect. You actually have 7 args and these should be:
> with ls_argc = 7
> ls_argv[0] = "ClientName"
> ls_argv[1] = "-ORBInitRef"
> ls_argv[2] = "NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService"
> ls_argv[3] = "-ORBDottedDecimalAddresses"
> ls_argv[4] = "1"
> ls_argv[5] = "-ORBSvcConf"
> ls_argv[6] = "ClientName.ORB.conf"
I agree with Simon's interpretation. However, does this interpretation
change the analysis that Florent did below and his proposed fix?
thanks,
Doug
> _______________________________________________
> ace-users mailing list
> ace-...@list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/ace-users
Chris Cleeland
On Nov 19, 2009, at 2:15 PM, Douglas C. Schmidt wrote:
>> You state that you are using:
>> with ls_argc = 4
>> ls_argv[0] = "ClientName"
>> ls_argv[1] = "-ORBInitRef
>> NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/NameService"
>> ls_argv[2] = "-ORBDottedDecimalAddresses 1"
>> ls_argv[3] = "-ORBSvcConf ClientName.ORB.conf"
>>
>> This is incorrect. You actually have 7 args and these should be:
>> with ls_argc = 7
>> ls_argv[0] = "ClientName"
>> ls_argv[1] = "-ORBInitRef"
>> ls_argv[2] = "NameService=corbaloc:iiop:AAA.BBB.CCC.DDD:1055/
>> NameService"
>> ls_argv[3] = "-ORBDottedDecimalAddresses"
>> ls_argv[4] = "1"
>> ls_argv[5] = "-ORBSvcConf"
>> ls_argv[6] = "ClientName.ORB.conf"
>
> I agree with Simon's interpretation. However, does this
> interpretation
> change the analysis that Florent did below and his proposed fix?
If I'm understanding what Florent wrote, then Simon's interpretation
(which is correct) does change Florent's analysis. Specifically,
Florent's analysis seem to be predicated on the notion that "-
ORBSvcConf foofilename" as a single arg should be correctly parsed as
an -ORBSvcConf option, and it shouldn't.
Like I said, maybe I'm misunderstanding the analysis, so if you had a
different understanding of that analysis, then it's possible you (and
Florent) are correct.
---
Chris Cleeland, Principal Software Engineer
http://www.theaceorb.com AND http://www.ociweb.com
Douglas C. Schmidt
Hi Chris,
> > I agree with Simon's interpretation. However, does this
> > interpretation
> > change the analysis that Florent did below and his proposed fix?
>
> If I'm understanding what Florent wrote, then Simon's interpretation
> (which is correct) does change Florent's analysis. Specifically,
> Florent's analysis seem to be predicated on the notion that "-
> ORBSvcConf foofilename" as a single arg should be correctly parsed as
> an -ORBSvcConf option, and it shouldn't.
Right, I agree that this isn't a single arg!
> Like I said, maybe I'm misunderstanding the analysis, so if you had a
> different understanding of that analysis, then it's possible you (and
> Florent) are correct.
I'm just trying to understand what the consequences of Simon's analysis
is. It sounds to me like Florent may need to tweak his code a bit.
Thanks,
Doug
> ---
> Chris Cleeland, Principal Software Engineer
> http://www.theaceorb.com AND http://www.ociweb.com
>
>
Chris Cleeland
On Nov 19, 2009, at 2:35 PM, Douglas C. Schmidt wrote:
>> Like I said, maybe I'm misunderstanding the analysis, so if you had a
>> different understanding of that analysis, then it's possible you (and
>> Florent) are correct.
>
> I'm just trying to understand what the consequences of Simon's
> analysis
> is. It sounds to me like Florent may need to tweak his code a bit.
yes, I agree that Florent needs to change code to look more like
Simon's than the original.