From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23898 invoked by alias); 11 Jul 2012 19:47:29 -0000 Received: (qmail 23888 invoked by uid 22791); 11 Jul 2012 19:47:28 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from bureau85.ns.utoronto.ca (HELO bureau85.ns.utoronto.ca) (128.100.132.185) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Jul 2012 19:47:13 +0000 Received: from [10.70.2.228] (sb-gw13.cs.toronto.edu [128.100.3.13]) (authenticated bits=0) by bureau85.ns.utoronto.ca (8.13.8/8.13.8) with ESMTP id q6BJlBFR030055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Jul 2012 15:47:12 -0400 Message-ID: <4FFDD841.6010705@cs.utoronto.ca> Date: Wed, 11 Jul 2012 19:47:00 -0000 From: Ryan Johnson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question) References: <1341539419.17571.ezmlm@cygwin.com> <1626e782b0218e6dbfa05f8930c36d46.squirrel@zeusw.org> In-Reply-To: <1626e782b0218e6dbfa05f8930c36d46.squirrel@zeusw.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-07/txt/msg00189.txt.bz2 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 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