[ http://issues.apache.org/jira/browse/AXISCPP-343?page=comments#action_12332263 ]
nadir amra commented on AXISCPP-343: ------------------------------------ Not sure if exact problem - but test cases are failing. The way arrays are handled in general is problematic and needs to be redesigned. I was never comfortable with memcpy/memset of objects because it is not good coding practice, but it did work on OS/400. But what is currently being done is equally bad. I am not that familiar with the code to understand what exactly needs to change to make this a cleaner implementation. Probably the quickest resolution to this would be the use of copy constructors - where one would loop through and assign each object to the other object in the array. More optimal solution would be to use some sort of AXISCPP-created container in the future so we do not have to recreate an array? > SIGSEGV deserializing an array of complex elements > -------------------------------------------------- > > Key: AXISCPP-343 > URL: http://issues.apache.org/jira/browse/AXISCPP-343 > Project: Axis-C++ > Type: Bug > Components: Serialization > Versions: 1.4 Final > Environment: RH9 > Reporter: Unai Uribarri > Fix For: 1.6 Alpha > Attachments: siaam.wsdl > > The function Axis_Create_* (in the following example, the mapItem > object) in the stubs generated by wsdl2ws java tool generates a SIGSEGV > when tring to enlarge an array of objects > mapItem* pNew = new mapItem[nSize]; > memcpy(pNew, pObj, sizeof(mapItem)*nSize/2); > memset(pObj, 0, sizeof(mapItem)*nSize/2); > --> delete [] pObj; <-- SIGSEGV > memset clears the virtual table pointer of the mapItem objects and the delete > operator crash. -- 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
