Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Ryan Johnson <ryan.johnson@cs.utoronto.ca>]

On 10/07/2012 12:46 PM, Claude SIMON wrote:
> Ryan Johnson wrote:
>> On 05/07/2012 9:36 AM, Claude SIMON wrote:
>>> Ryan Johnson wrote:
>>>> On 04/07/2012 5:45 AM, Claude SIMON wrote:
>>>>> When I compile the component with Visual C++, it works. When I compile
>>>>> the
>>>>> component with g++... it crashes.
>>>>>
>>>>> With 'gdb', I found that the problem happens when calling the 'malloc'
>>>>> function (as soon as the function is called, NOT when the returned
>>>>> allocated memory is used). When I replace the 'malloc' by a the C++
>>>>> 'new'
>>>>> operator, the component compiled with Cygwin g++ doesn't crash
>>>>> anymore.
>>>>> I thought that the C++ 'new' operator calls the 'malloc' function, but
>>>>> this seems not to be the case. As I want to use 'malloc'-like
>>>>> functions
>>>>> rather than the C++ 'new' operator, I wonder which functions are used
>>>>> in
>>>>> the C++ 'new' operator to allocate memory (and naturally which
>>>>> functions
>>>>> are used in the C++ 'delete' operator to free the memory).
>>>> Operator new() and malloc() are explicitly *not* interchangeable (for
>>>> many reasons, not least of which that the Standard says so). If you
>>>> were
>>>> to free new'ed memory, or delete malloc'ed memory, the resulting heap
>>>> corruption could easily manifest as a crash the next time you tried to
>>>> allocate something... or it might just silently clobber data and lead
>>>> to
>>>> "spooky action at a distance."
>>>>
>>> Thank you for the answer, but I am aware of this and my problem has
>>> nothing to do with it, nor, as stated in the subject, with having some
>>> lacuna in C/C++ programming.
>>>
>>> Let's try to be a little more explicit despite my poor English.
>>>
>>> Let's consider a Java native component which only calls a 'malloc(1)'.
>>> It
>>> doesn't even test the returned value (it is usually not a good idea, but
>>> it doesn't matter here).
>>>
>>> This component :
>>> - compiled with g++ under Linux : works,
>>> - compiled with g++ under Mac OS : works,
>>> - compiled with Visual C++ under Windows : works,
>>> - compiled with g++ under Cygwin : CRASHES !
>>>
>>> It crashes as soon the 'malloc(1)' function is called. You don't even
>>> have
>>> the opportunity to test the returned value, nor to use it. It's perhaps
>>> a
>>> Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't
>>> bother
>>> (but if someone will make some investigation about that, I'm ready to
>>> help
>>> him or her if I can).
>>>
>>> When you replace the 'malloc()' by the 'new' operator, then the
>>> component
>>> compiled with g++ under Cygwin works too.
>>> The 'new' operator, among other things, allocates memory, as 'malloc()'
>>> does, but obviously it doesn't use 'malloc()' as it doesn't crash. So,
>>> because I can't use 'malloc()' in my Java native components, and because
>>> I
>>> doesn't want to use the 'new' operator, I wish to know which functions
>>> the
>>> 'new' operator uses to allocate memory, so I can use them in my Java
>>> native component so they would no more crash when compiled with g++
>>> under
>>> Cygwin.
>> A crash inside malloc is 99.99% likely due to a bug in user code (wild
>> pointer, double-free, smashed stack, etc). The fact that your code
>> doesn't crash under other circumstances does precisely *nothing* to rule
>> out a bug in your code if bad has been observed anywhere (it just proves
>> the platforms really are different). The buggy code may have nothing to
>> do with malloc, other than having the bad luck of clobbering a data
>> structure the latter needs. Even a single mix-up of new/malloc usage
>> (perhaps due to losing track of a pointer's provenance) is also enough.
> Indeed. The problem is... the crash happens even when there is no other
> code which could be buggy.
#include <stdlib.h>
int main() { return (int) malloc(10); }

Does not crash. There must be some other code which is buggy.

> As asked in another reply to this thread, I've made a test case, which can
> be found at :
> 	http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
> There is a README file which contains some further explanations.
If it needs to live in a CVS repo, it's not a simple test case. Those 
usually fit inline in emails (see above). Long test cases are acceptable 
if the problem can't be narrowed down further, but you'll need to make a 
substantial effort to exclude bugs in your own code before others will 
be interested to jump in. Like running a debug allocator.
>
>> This is all standard memory management debugging stuff that's off topic
>> for this list. If at some point you have some evidence besides "it
>> crashes when I run it under cygwin" *that* would be a topic for this list.
> With the test case above, I think that it is easy to establish if the
> problem is off or on topic.
Great. Please do.

>
>> My suggestion: run under the debugging malloc library of your choice
>> and/or Valgrind and see what that turns up.
> Should be interesting to see if a alternative 'malloc' would also crash,
> but would not solve my problem given what I wrote above.
Why not? Try it, you might be surprised.

>> As to your question, new() usually calls malloc under the hood (with
>> extra bookkeeping), but five minutes with gdb will give you a definitive
>> answer.
>>
> I don't manage to make 'gdb' step into a 'new' call...
b _malloc
r

> Beside the crash thing, all I'm interested into, is if someone here can
> show me the implementation of the 'new' operator as used in Cygwin, or
> give me an address where I can found the source code of this 'new'
> implementation, or where I may ask this questions to obtain a response to
> one of this question.
It's burned into gcc. That's why I highly doubt cygwin's code is 
directly causing the problem here.

To be blunt, you appear to be a help vampire [1]. You haven't actually 
done any visible legwork, even the things people have taken time to 
suggest you try. I am done with this thread unless/until you do 
something to dispel that perception.

[1] http://slash7.com/2006/12/22/vampires/

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple