delete void* undefined using gcc

[Emanuel Norrbin <em...@jitterbit.com>]

Hi all,

when I compile the latest svn version ( revision 386160 from March 15 )  of 
the Axis C++ server I get the following compile warning from gcc ( gcc (GCC) 
3.4.4 20050721 (Red Hat 3.4.4-2)):

[cc] /ws-axis/obj/src/common/ArrayBean.cpp:329: warning: deleting `void*' is 
undefined

I have a web service that returns a string array, i.e.the implementation 
returns a xsd__string_Array*

When I run the SimpleAxisServer using valgrind (http://valgrind.org/) I get 
the following error:

Mismatched free() / delete / delete []
   at 0x401C1F6: operator delete(void*) (vg_replace_malloc.c:246)
   by 0x40D1DE3: axiscpp::ArrayBean::~ArrayBean() (ArrayBean.cpp:329)
   by 0x40D3744: axiscpp::Param::~Param() (Param.cpp:69)
   by 0x40DF8B0: axiscpp::SoapMethod::clearOutParams() (stl_list.h:131)
   by 0x40DFAA2: axiscpp::SoapMethod::~SoapMethod() (SoapMethod.cpp:70)
   by 0x40C0920: axiscpp::SoapBody::~SoapBody() (SoapBody.cpp:74)
   by 0x40CDBF7: axiscpp::SoapEnvelope::~SoapEnvelope() 
(SoapEnvelope.cpp:97)
   by 0x40E6DAC: axiscpp::SoapSerializer::init() (SoapSerializer.cpp:623)
   by 0x4087288: 
axiscpp::SerializerPool::getInstance(axiscpp::IWrapperSoapSerializer**) 
(SerializerPool.cpp:97)
   by 0x40ADC9B: axiscpp::AxisEngine::initialize() (AxisEngine.cpp:118)
   by 0x40DECD1: process_request(axiscpp::SOAPTransport*) (Axis.cpp:252)
   by 0x804BB48: handleTCPClient(int) (SimpleAxisServer.cpp:174)

 Address 0x540C478 is 0 bytes inside a block of size 28 alloc'd
   at 0x401BC26: operator new[](unsigned) (vg_replace_malloc.c:197)
   by 0x409B82B: axiscpp::Axis_Array::set(void**, int, axiscpp::XSDTYPETag) 
(AxisUserAPI.cpp:498)
   by 0x409C2F6: axiscpp::Axis_Array::clone(axiscpp::Axis_Array const&) 
(AxisUserAPI.cpp:446)
   by 0x409C3C1: axiscpp::Axis_Array::Axis_Array(axiscpp::Axis_Array const&) 
(AxisUserAPI.cpp:428)
   by 0x409C44D: axiscpp::Axis_Array::clone() const (AxisUserAPI.cpp:465)
   by 0x40E4C5B: 
axiscpp::SoapSerializer::addOutputBasicArrayParam(axiscpp::Axis_Array 
const*, axiscpp::XSDTYPETag, char const*) (SoapSerializer.cpp:256)
   by 0x59AAB4B: ActivityInfoProviderWrapper::getOperationLog(void*) 
(ActivityInfoProviderWrapper.cpp:221)
   by 0x59AA006: ActivityInfoProviderWrapper::invoke(void*) 
(ActivityInfoProviderWrapper.cpp:50)
   by 0x408156E: axiscpp::ServerAxisEngine::invoke(axiscpp::MessageData*) 
(ServerAxisEngine.cpp:504)
   by 0x4082E33: axiscpp::ServerAxisEngine::process(axiscpp::SOAPTransport*) 
(ServerAxisEngine.cpp:312)
   by 0x40DED8F: process_request(axiscpp::SOAPTransport*) (Axis.cpp:254)
   by 0x804BB48: handleTCPClient(int) (SimpleAxisServer.cpp:174)

So the memory that was created using

    m_Array = new void*[m_Size];

is deleted using

    delete [] m_value.sta;

m_value is defined as:

union uAValue //this is useful only when Param is used as a return parameter
{
    void *sta; //simple type array
    ComplexObjectHandler *cta; //complex type array
}
m_value;

so delete [] is called on a void* which is the same pointer created by new[] 
above. This seems to be ok on windows using the msvc compiler. On Linux, 
however, using gcc 3.4.4, the code actually generated uses plain delete (as 
can be seen from the stack trace above) so at best there will be a memory 
leak and at worst undefined behaviour.

This might not be too bad but since the compiler says that deleting a void* 
is undefined maybe it would be better to do something else.

The best thing to do would be to make Axis_Array a template but it might be 
too late now or there might be other issues involved with that approach that 
I am not aware of. The other solution is to introduce another switch 
(m_Type) when the array is created, like so (in AxisUserApi.cpp):

switch(m_Type) {
    case XSD_DURATION:
        m_Array = new xsd__duration*[m_Size];
... and so on ...
}

and the delete switch would be:

switch case(m_type) {
    case XSD_DURATION:
        delete [] (xsd__duration*)m_value.sta
... and so on ...
}

this would new[] and delete[] the memory correctly.

Has anyone run into this issue before? Should I open an issue in Jira for 
this?

Besides this I have not found any major issues in the latest 1.6 beta. It 
looks very promising, keep up the good work guys!

/Cheers
Emanuel