[
https://issues.apache.org/jira/browse/AXIS2C-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547275
]
Bill Mitchell commented on AXIS2C-783:
--------------------------------------
After updating to svn rev 599902, I have verified that when the
axis2_mod_addr.dll is missing, error 27 is correctly generated.
Yes, Dinesh, I did try a couple days ago to generate a diff file to provide
with my report. But the local version of svn at this site has been customized
to always run windiff. Great for seeing the differences but not so great for
providing them in a file format. I've not yet researched how to get to a
standard version of svn diff to use just for the purpose of providing the patch
files.
> Client seg faults if AXIS2C_HOME variable not set
> -------------------------------------------------
>
> Key: AXIS2C-783
> URL: https://issues.apache.org/jira/browse/AXIS2C-783
> Project: Axis2-C
> Issue Type: Bug
> Components: code generation, core/clientapi, core/deployment
> Affects Versions: 1.1.0
> Environment: Window XP, Visual Studio 2005
> Reporter: Bill Mitchell
> Assignee: Dinesh Premalal
> Fix For: 1.2.0
>
>
> If the AXIS2C_HOME variable is not set, or if the client application code
> sets the ClientHome argument to a directory that does not containt axis2.xml
> and related files, the client application fails with a segmentation fault.
> Investigating this uncovered several issues, best described by highlighting
> the relevant actions in the code in chronological order:
> (1) axis2_dep_engine_check_client_home() in depengine.c detects the problem
> and stores an error code, AXIS2_ERROR_CONFIG_NOT_FOUND (18). But processing
> at this point is allowed to continue.
> (2) axis2_conf_builder_create_with_file_and_dep_engine_and_conf(), in
> particular axis2_desc_builder_create_with_file_and_dep_engine(), then changes
> the status_code in the environment error structure back to success. This is
> a side-effect of invoking the AXIS2_PARM_CHECK macro.
> (3) In axis2_desc_builder_build_om(), the call to
> axiom_xml_reader_create_for_file() returns an error, but the error number has
> now been replaced
> with AXIS2_ERROR_CREATING_XML_STREAM_READER(141).
> Axis2_desc_builder_build_om() then replaces this error number with the same
> value, just to
> make sure it is well and truly changed.
> (4) In stub.c, axis2_stub_create_with_endpoint_ref_and_client_home() replaces
> the error 141 with a truly misleading AXIS2_ERROR_NO_MEMORY(2).
> (5) In the generated stub code to create the service,
> axis2_stub_servicename_create() ignores the fact that the returned stub
> pointer is zero and goes ahead and calls
> axis2_stub_servicename_populate_services() anyway, where the code dies
> dereferencing the zero pointer.
> Recommendations:
> (5) In the generated stub code for axis2_stub_servicename_create(), the
> fragment
> stub = axis2_stub_create_with_endpoint_ref_and_client_home ( env,
> endpoint_ref, client_home );
> axis2_stub_servicename_populate_services( stub, env );
> return stub;
> should read:
> stub = axis2_stub_create_with_endpoint_ref_and_client_home ( env,
> endpoint_ref, client_home );
> if (stub)
> {
> axis2_stub_servicename_populate_services( stub, env );
> }
> return stub;
> (4) In stub.c, the procedure
> axis2_stub_create_with_endpoint_ref_and_client_home() really needs to let the
> underlying error number be returned. In the fragment:
> /* create service_client*/
> stub->svc_client = axis2_svc_client_create(env , client_home);
> if (!stub->svc_client)
> {
> axis2_stub_free(stub, env);
> AXIS2_ERROR_SET(env->error, AXIS2_ERROR_NO_MEMORY, AXIS2_FAILURE);
> return NULL;
> }
> the AXIS2_ERROR_SET invocation should be removed.
> (1) Where the client has passed a clienthome parameter, but it does not point
> to a valid Axis2C home directory structure, I prefer the first error code
> AXIS2_ERROR_CONFIG_NOT_FOUND to the second
> AXIS2_ERROR_CREATING_XML_STREAM_READER. So I suggest that
> axis2_dep_engine_load_client() in depengine.c be changed to treat this as an
> immediate error instead of letting processing continue. The fragment:
> if (client_home && 0 != axutil_strcmp("", client_home))
> {
> status = axis2_dep_engine_check_client_home(dep_engine, env,
> client_home);
> if (AXIS2_SUCCESS == status)
> {
> is_repos_exist = AXIS2_TRUE;
> }
> }
> else
> could be changed to:
> if (client_home && 0 != axutil_strcmp("", client_home))
> {
> status = axis2_dep_engine_check_client_home(dep_engine, env,
> client_home);
> if (AXIS2_SUCCESS != status)
> {
> return NULL;
> }
> is_repos_exist = AXIS2_TRUE;
> }
> else
> Of course, there may be a good reason to want to continue processing that I
> have not uncovered. In this case, you could instead do something to resolve
> item(2), such that the original error code could be returned instead of
> overlaying it as happens at point (3).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
