You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Steve Hardy (JIRA)" <ax...@ws.apache.org> on 2004/12/19 17:00:13 UTC
[jira] Created: (AXISCPP-329) NIL xsd:string type segfaults server in RPC/Encoded
NIL xsd:string type segfaults server in RPC/Encoded
---------------------------------------------------
Key: AXISCPP-329
URL: http://nagoya.apache.org/jira/browse/AXISCPP-329
Project: Axis-C++
Type: Bug
Components: Serialization/Deserialization
Versions: current (nightly)
Environment: tested on win32 with rpc/encoded
Reporter: Steve Hardy
There is no (correct) handling in SoapDeSerializer for NIL xsd:string types in rpc/encoded. This causes SoapDeSerializer::getXSDType to use a NULL pointer returned by splitQNameString to be passed to getNS4Prefix, which subsequently segfaults. I'm not sure whether this is due to the client sending the wrong tag, but this should be fixed on the server in any case.
In my test case, the attributes are only:
+ [0x0] 0x01218548 "nil"
+ [0x1] 0x01218590 "http://www.w3.org/2001/XMLSchema-instance"
+ [0x2] 0x012185f8 "true"
so the type is missing here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AXISCPP-329) NIL xsd:string type segfaults server in RPC/Encoded
Posted by "Chinthana Danapala (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-329?page=all ]
Chinthana Danapala resolved AXISCPP-329:
----------------------------------------
Resolution: Fixed
Add support to handle nil values in RPC/Encoded.
Sending ..........................................
<?xml version='1.0' encoding='utf-8' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ns1:doGetSummary xmlns:ns1="urn:ADEC_MAST">
<String1 xsi:nil="true"></String1>
<String2 xsi:type="xsd:string">http://www.w3.org/2001/XMLSchema-instance</String2>
<String0 xsi:type="xsd:string">true</String0>
</ns1:doGetSummary>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Received.............................
<?xml version='1.0' encoding='utf-8' ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ns1:doGetSummaryResponse xmlns:ns1="urn:ADEC_MAST">
<SummaryResult xsi:type="ns1:SummaryResult"><Value0 xsi:nil="true"></Value0>
<Value1 xsi:type="xsd:string">http://www.w3.org/2001/XMLSchema-instance</Value1>
<Value2 xsi:type="xsd:string">true</Value2>
</SummaryResult></ns1:doGetSummaryResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
> NIL xsd:string type segfaults server in RPC/Encoded
> ---------------------------------------------------
>
> Key: AXISCPP-329
> URL: http://issues.apache.org/jira/browse/AXISCPP-329
> Project: Axis-C++
> Type: Bug
> Components: Server - Engine
> Versions: current (nightly)
> Environment: tested on win32 with rpc/encoded
> Reporter: Steve Hardy
> Assignee: Chinthana Danapala
>
> There is no (correct) handling in SoapDeSerializer for NIL xsd:string types in rpc/encoded. This causes SoapDeSerializer::getXSDType to use a NULL pointer returned by splitQNameString to be passed to getNS4Prefix, which subsequently segfaults. I'm not sure whether this is due to the client sending the wrong tag, but this should be fixed on the server in any case.
> In my test case, the attributes are only:
> + [0x0] 0x01218548 "nil"
> + [0x1] 0x01218590 "http://www.w3.org/2001/XMLSchema-instance"
> + [0x2] 0x012185f8 "true"
> so the type is missing here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (AXISCPP-329) NIL xsd:string type segfaults server in RPC/Encoded
Posted by "Chinthana Danapala (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-329?page=all ]
Chinthana Danapala reassigned AXISCPP-329:
------------------------------------------
Assign To: Chinthana Danapala
> NIL xsd:string type segfaults server in RPC/Encoded
> ---------------------------------------------------
>
> Key: AXISCPP-329
> URL: http://issues.apache.org/jira/browse/AXISCPP-329
> Project: Axis-C++
> Type: Bug
> Components: Server - Engine
> Versions: current (nightly)
> Environment: tested on win32 with rpc/encoded
> Reporter: Steve Hardy
> Assignee: Chinthana Danapala
>
> There is no (correct) handling in SoapDeSerializer for NIL xsd:string types in rpc/encoded. This causes SoapDeSerializer::getXSDType to use a NULL pointer returned by splitQNameString to be passed to getNS4Prefix, which subsequently segfaults. I'm not sure whether this is due to the client sending the wrong tag, but this should be fixed on the server in any case.
> In my test case, the attributes are only:
> + [0x0] 0x01218548 "nil"
> + [0x1] 0x01218590 "http://www.w3.org/2001/XMLSchema-instance"
> + [0x2] 0x012185f8 "true"
> so the type is missing here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-329) NIL xsd:string type segfaults server in RPC/Encoded
Posted by "Chinthana Danapala (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-329?page=comments#action_12314844 ]
Chinthana Danapala commented on AXISCPP-329:
--------------------------------------------
Can you attach the WSDL file and client and server implementation so it's easy to recreate the problem?
> NIL xsd:string type segfaults server in RPC/Encoded
> ---------------------------------------------------
>
> Key: AXISCPP-329
> URL: http://issues.apache.org/jira/browse/AXISCPP-329
> Project: Axis-C++
> Type: Bug
> Components: Server - Engine
> Versions: current (nightly)
> Environment: tested on win32 with rpc/encoded
> Reporter: Steve Hardy
>
> There is no (correct) handling in SoapDeSerializer for NIL xsd:string types in rpc/encoded. This causes SoapDeSerializer::getXSDType to use a NULL pointer returned by splitQNameString to be passed to getNS4Prefix, which subsequently segfaults. I'm not sure whether this is due to the client sending the wrong tag, but this should be fixed on the server in any case.
> In my test case, the attributes are only:
> + [0x0] 0x01218548 "nil"
> + [0x1] 0x01218590 "http://www.w3.org/2001/XMLSchema-instance"
> + [0x2] 0x012185f8 "true"
> so the type is missing here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-329) NIL xsd:string type segfaults server in RPC/Encoded
Posted by "John Hawkins (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-329?page=history ]
John Hawkins updated AXISCPP-329:
---------------------------------
Component: Server - Engine
(was: Serialization)
> NIL xsd:string type segfaults server in RPC/Encoded
> ---------------------------------------------------
>
> Key: AXISCPP-329
> URL: http://issues.apache.org/jira/browse/AXISCPP-329
> Project: Axis-C++
> Type: Bug
> Components: Server - Engine
> Versions: current (nightly)
> Environment: tested on win32 with rpc/encoded
> Reporter: Steve Hardy
>
> There is no (correct) handling in SoapDeSerializer for NIL xsd:string types in rpc/encoded. This causes SoapDeSerializer::getXSDType to use a NULL pointer returned by splitQNameString to be passed to getNS4Prefix, which subsequently segfaults. I'm not sure whether this is due to the client sending the wrong tag, but this should be fixed on the server in any case.
> In my test case, the attributes are only:
> + [0x0] 0x01218548 "nil"
> + [0x1] 0x01218590 "http://www.w3.org/2001/XMLSchema-instance"
> + [0x2] 0x012185f8 "true"
> so the type is missing here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXISCPP-329) NIL xsd:string type segfaults server
in RPC/Encoded
Posted by "Fred Preston (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-329?page=all ]
Fred Preston closed AXISCPP-329:
--------------------------------
> NIL xsd:string type segfaults server in RPC/Encoded
> ---------------------------------------------------
>
> Key: AXISCPP-329
> URL: http://issues.apache.org/jira/browse/AXISCPP-329
> Project: Axis-C++
> Type: Bug
> Components: Server - Engine
> Versions: current (nightly)
> Environment: tested on win32 with rpc/encoded
> Reporter: Steve Hardy
> Assignee: Chinthana Danapala
>
> There is no (correct) handling in SoapDeSerializer for NIL xsd:string types in rpc/encoded. This causes SoapDeSerializer::getXSDType to use a NULL pointer returned by splitQNameString to be passed to getNS4Prefix, which subsequently segfaults. I'm not sure whether this is due to the client sending the wrong tag, but this should be fixed on the server in any case.
> In my test case, the attributes are only:
> + [0x0] 0x01218548 "nil"
> + [0x1] 0x01218590 "http://www.w3.org/2001/XMLSchema-instance"
> + [0x2] 0x012185f8 "true"
> so the type is missing here.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira