[ http://issues.apache.org/jira/browse/AXISCPP-343?page=comments#action_12332318 ]
nadir amra commented on AXISCPP-343: ------------------------------------ Dushshantha, I do not blame anyone for the problems I am seeing. The errors I am seeing is due to the differences between UNIX/Windows and OS/400. I run the unit tests. In UNIX/windows, programmers assume that pointers and integers are inter-changable. That is not true on OS/400, and I would think that is not true on 64-bit machines (of which OS/400 is). Although it is common practice to treat them the same in UNIX/windows-land, it is not really, in my opinion, good coding practice. With the current problems I am seeing, it is assumed that performing the memory copies of the class in chunks is OK. Obviously, it is not good coding practice to do so (neither was the original implementation with memcpy/memset, although that kind of worked on OS/400). In this case, due to the protection mechanisms built-into the OS/400, the copying of data in this way invalidates any pointers that may be in the object. I think I have come up with an interim solution that I will be testing in the next couple of days that should be acceptable on all platforms. In the long term, we should think about copy-constructors or better array implementation, possibly using an AXIS container that simulates an array via linked lists. But basically, I hope developers realize that when coding, integers are not interchangable with pointers and object copying should be performed in a portable, object-oriented way in order for the code to work on a variety of platforms. > 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
