From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27314 invoked by alias); 27 Sep 2007 11:54:43 -0000 Received: (qmail 27305 invoked by uid 22791); 27 Sep 2007 11:54:42 -0000 X-Spam-Check-By: sourceware.org Received: from rwcrmhc13.comcast.net (HELO rwcrmhc13.comcast.net) (216.148.227.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Sep 2007 11:54:36 +0000 Received: from rickmce (c-68-55-175-129.hsd1.md.comcast.net[68.55.175.129]) by comcast.net (rwcrmhc13) with SMTP id <20070927115434m130024s0se>; Thu, 27 Sep 2007 11:54:34 +0000 From: "Rick Davis" To: "'Johan Cederbom'" Cc: "'Andrew Lunn'" , "'Ecos-Discuss'" References: <00a701c8009c$82b1d5d0$88158170$@net> <46FB5D8B.8050808@logopak.se> In-Reply-To: <46FB5D8B.8050808@logopak.se> Date: Thu, 27 Sep 2007 11:54:00 -0000 Message-ID: <00af01c800fd$610ee0b0$232ca210$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] Doug Lea's malloc X-SW-Source: 2007-09/txt/msg00142.txt.bz2 Johan, I found it! Stupid logic error trying to align my buffer to the HAL_DCACHE_LINE_SIZE. I allocated enough but forgot to add (HAL_DCACHE_LINE_SIZE-1) before anding with ~(HAL_DCACHE_LINE_SIZE-1). Thanks for the response, Rick -----Original Message----- From: Johan Cederbom [mailto:jcederbom@logopak.se] Sent: Thursday, September 27, 2007 3:37 AM To: Rick Davis Cc: 'Andrew Lunn'; 'Ecos-Discuss' Subject: Re: [ECOS] Doug Lea's malloc Hi Andrew, I've just spent a week with a similar problem (on another system). You get the assertion because someone has written over the memory allocation structures, and the ASSERT/DEBUG flag in "dynamic memory allocation" -> ".. implemetations" -> "Doug Lea's" is enabled. All allocated memory areas are separated by a simple "memchunk" structure. If a task wites more bytes than allocated, it will destroy theese "memchunk" structures. The assertion comes when trying to use the bad struct and that is always too late, the memory has already been trashed. The tricky part is to find out who did it ! /Johan Rick Davis wrote: > Andrew, > > Sorry it took so long to get back. > > Here is the dump I get when calling setvbuf (stdout, NULL, _IONBUF, 0); > > ASSERT FAIL: <5>dlmalloc.cxx[815]void > Cyg_Mempool_dlmalloc_Implementation::do_check_inuse_chunk() > ((((mchunkptr)(((char*)(p))+((p)->size & ~0x1)))->size) & 0x1) > ASSERT FAIL: dlmalloc.cxx [ 815] void > Cyg_Mempool_dlmalloc_Implementation::do_check_inuse_chunk() > ((((mchunkptr)(((char*)(p))+((p)->size & ~0x1)))->size) & 0x1) > > Rick > > > -----Original Message----- > From: Andrew Lunn [mailto:andrew@lunn.ch] > Sent: Thursday, September 13, 2007 4:59 PM > To: Rick Davis > Cc: Ecos-Discuss > Subject: Re: [ECOS] dOUG lEE'S MALLOC > > On Thu, Sep 13, 2007 at 03:42:36PM -0400, Rick Davis wrote: > >> I am porting to a new Power-PC platform that has 256M of DDR on it. I am >> using the latest snapshot (today as a matter of fact). If I call setvbuf >> (stdout, NULL, _IONBF, 0), Doug's code complains throwing some sort of >> > size > >> assertion. If I don't call setvbuf but call show_memory, that complains >> about other issues. If I use the simple malloc routines instead, >> > everything > >> works fine. Is there a memory size issue? Is something not being called in >> the right order during initialization? >> > > Do you have a simple test case? > > I just tried running the synthetic target which a big heap. All the > malloc tests pass. eg malloc4 produces: > > INFO: > INFO: maxfree=276507324> > INFO: maxfree=29058556> > INFO: maxfree=58859852> > INFO: maxfree=65494596> > INFO: maxfree=1714036> > INFO: maxfree=38098124> > INFO: maxfree=58928772> > INFO: maxfree=36578764> > INFO: maxfree=77573924> > INFO: maxfree=23496868> > INFO: maxfree=29280524> > INFO: maxfree=100678860> > INFO: maxfree=39697388> > INFO: maxfree=110641924> > INFO: maxfree=95249636> > INFO: maxfree=31240340> > INFO: maxfree=109160292> > INFO: maxfree=5096676> > INFO: maxfree=106951988> > INFO: maxfree=89131924> > INFO: maxfree=140538356> > INFO: maxfree=276507324> > PASS: > EXIT: > > Here the heap is around 263Mbytes. > > What exactly are the assertion failures you are getting? > > Andrew > > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss