[ECOS] dOUG lEE'S MALLOC

[ECOS] dOUG lEE'S MALLOC

[Rick Davis]

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?

I was also having issue programming my 64M of 32 bit wide Spansion FLASH
with Doug's routines. The issue seems to have disappeared using the simple
malloc functions.

Rick Davis



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Question on serial ports

[Scott Moore]

 
Hi, I am working with a Keil MCB2300 board. I had a question on serial port
implementations.

Our installation was derived from the ARM/MCB2100 board which comes with
ECOS, using the lpc2xxx structures.

Included with the standard build is the diagnostic port haldiag, which is
layered as ttydiag. The hal for the board includes code to access both
ports, 0 and 1 on the board. However, the code does not appear to support
more than a single port at the device level. The code does not appear
to support interrupts, and uses the SERIAL_CHANNEL macro as opposed to
the SERIAL_CHANNEL_USING_INTERRUPTS macro. Basically it appears that
this installation was only designed to support a single diagnostics
serial port which doubles as a GDB access port.

under /packages/devs/serial, there is a directory for arm/lpc2xxx, but
it contains the single file arm_lpc2xxx_ser.inl, which appears to just
contain the headers for a possible driver. The functions defined in this
file don't appear to go anywhere, for example "pc_serial_init", etc.

The questions are:

1. Does this indeed indicate that a full (not diagnostic) serial port
implementation was never completed for the MCB2100 board?

2. What was the purpose of the directory 
../packages/devs/serial/arm/lpc2xxx/..? Was this just a placeholder for
where a device might go?

Thank you,

Scott Moore
Powerfile

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] dOUG lEE'S MALLOC

[Andrew Lunn]

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:<Starting malloc4 test>
INFO:<Iteration 0, arenasize=276507344, space free=276507324, maxfree=276507324>
INFO:<Iteration 10, arenasize=276507344, space free=31489948, maxfree=29058556>
INFO:<Iteration 20, arenasize=276507344, space free=108284148, maxfree=58859852>
INFO:<Iteration 30, arenasize=276507344, space free=69580420, maxfree=65494596>
INFO:<Iteration 40, arenasize=276507344, space free=1714036, maxfree=1714036>
INFO:<Iteration 50, arenasize=276507344, space free=92251804, maxfree=38098124>
INFO:<Iteration 60, arenasize=276507344, space free=111664980, maxfree=58928772>
INFO:<Iteration 70, arenasize=276507344, space free=47689060, maxfree=36578764>
INFO:<Iteration 80, arenasize=276507344, space free=77573924, maxfree=77573924>
INFO:<Iteration 90, arenasize=276507344, space free=34070540, maxfree=23496868>
INFO:<Iteration 100, arenasize=276507344, space free=29280524, maxfree=29280524>
INFO:<Iteration 110, arenasize=276507344, space free=142085116, maxfree=100678860>
INFO:<Iteration 120, arenasize=276507344, space free=92516524, maxfree=39697388>
INFO:<Iteration 130, arenasize=276507344, space free=178518644, maxfree=110641924>
INFO:<Iteration 140, arenasize=276507344, space free=95249636, maxfree=95249636>
INFO:<Iteration 150, arenasize=276507344, space free=58732380, maxfree=31240340>
INFO:<Iteration 160, arenasize=276507344, space free=154251700, maxfree=109160292>
INFO:<Iteration 170, arenasize=276507344, space free=8964580, maxfree=5096676>
INFO:<Iteration 180, arenasize=276507344, space free=129668932, maxfree=106951988>
INFO:<Iteration 190, arenasize=276507344, space free=89131924, maxfree=89131924>
INFO:<Iteration 200, arenasize=276507344, space free=198999364, maxfree=140538356>
INFO:<Iteration 203, arenasize=276507344, space free=276507324, maxfree=276507324>
PASS:<malloc4 test completed successfully>
EXIT:<done>

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

Re: [ECOS] Question on serial ports

[Andrew Lunn]

> The questions are:
> 
> 1. Does this indeed indicate that a full (not diagnostic) serial port
> implementation was never completed for the MCB2100 board?
> 
> 2. What was the purpose of the directory 
> ../packages/devs/serial/arm/lpc2xxx/..? Was this just a placeholder for
> where a device might go?

Take a look at the targets which use this:

target p2106 {
        alias { "Olimex evaluation board LPC-P2106" p2106 }
        packages { CYGPKG_HAL_ARM
                   CYGPKG_HAL_ARM_LPC2XXX
                   CYGPKG_HAL_ARM_LPC2XXX_P2106
                   CYGPKG_IO_SERIAL_GENERIC_16X5X
                   CYGPKG_IO_SERIAL_ARM_LPC2XXX
                   CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX
        }
        description "
        The p2106 target provides the packages needed to run eCos on the
        LPC-P2106 evaluation board from Olimex."
}

target lpcmt {
        alias { "Olimex evaluation board LPC-LPCMT" lpcmt }
        packages { CYGPKG_HAL_ARM
                   CYGPKG_HAL_ARM_LPC2XXX
                   CYGPKG_HAL_ARM_LPC2XXX_LPCMT
                   CYGPKG_IO_SERIAL_GENERIC_16X5X
                   CYGPKG_IO_SERIAL_ARM_LPC2XXX
                   CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX
        }
        description "
        The lpcmt target provides the packages needed to run eCos on the
        LPC-LPCMT evaluation board from Olimex."
}

Looking at this suggests that the LPC2XXX serial driver is just what
is needed to make the generic 16x5x serial driver work on LPC
targets. Take a closer look at one of the these targets and all should
become clear...

       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

RE: [ECOS] Question on serial ports

[Scott Moore]

Thank you. 

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: Thursday, September 13, 2007 2:04 PM
To: Scott Moore
Cc: Ecos-Discuss; Steve Gaskill
Subject: Re: [ECOS] Question on serial ports

> The questions are:
> 
> 1. Does this indeed indicate that a full (not diagnostic) serial port 
> implementation was never completed for the MCB2100 board?
> 
> 2. What was the purpose of the directory 
> ../packages/devs/serial/arm/lpc2xxx/..? Was this just a placeholder 
> for where a device might go?

Take a look at the targets which use this:

target p2106 {
        alias { "Olimex evaluation board LPC-P2106" p2106 }
        packages { CYGPKG_HAL_ARM
                   CYGPKG_HAL_ARM_LPC2XXX
                   CYGPKG_HAL_ARM_LPC2XXX_P2106
                   CYGPKG_IO_SERIAL_GENERIC_16X5X
                   CYGPKG_IO_SERIAL_ARM_LPC2XXX
                   CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX
        }
        description "
        The p2106 target provides the packages needed to run eCos on the
        LPC-P2106 evaluation board from Olimex."
}

target lpcmt {
        alias { "Olimex evaluation board LPC-LPCMT" lpcmt }
        packages { CYGPKG_HAL_ARM
                   CYGPKG_HAL_ARM_LPC2XXX
                   CYGPKG_HAL_ARM_LPC2XXX_LPCMT
                   CYGPKG_IO_SERIAL_GENERIC_16X5X
                   CYGPKG_IO_SERIAL_ARM_LPC2XXX
                   CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX
        }
        description "
        The lpcmt target provides the packages needed to run eCos on the
        LPC-LPCMT evaluation board from Olimex."
}

Looking at this suggests that the LPC2XXX serial driver is just what is needed to make the generic 16x5x serial driver work on LPC targets. Take a closer look at one of the these targets and all should become clear...

       Andrew

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Question on serial ports

[Scott Moore]

Hi, sorry to post on this yet again, but I built both
the p2106 and lpcmt targets, and both appear to have the
same (forgive me) braindamaged I/O as the mcb2100 board
target. I tried:

C:\projects\testbuild>ecosconfig add CYGPKG_IO_SERIAL_GENERIC_16X5X
Package `CYGPKG_IO_SERIAL_GENERIC_16X5X' is already loaded.

And the configurator appears to believe that this is already selected.
However, after building, I don't see the ser_16x5x.o file anywhere
in the build. ser_16x5x.c is the file 
../ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x which
contains the 16x5x general support. Instead it is including:

09/14/2007  01:47 PM            23,264 io_serial_haldiag.o
09/14/2007  01:47 PM            26,808 io_serial_serial.o
09/14/2007  01:47 PM            21,488 io_serial_tty.o

haldiag is the package that includes the stripped down, polling
mode only I/O.

What's the trick to getting this package (really) included in the
build?

Thank you,

Scott Moore

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Scott Moore
Sent: Thursday, September 13, 2007 2:12 PM
To: Andrew Lunn
Cc: Ecos-Discuss; Steve Gaskill
Subject: RE: [ECOS] Question on serial ports

Thank you. 

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Thursday, September 13, 2007 2:04 PM
To: Scott Moore
Cc: Ecos-Discuss; Steve Gaskill
Subject: Re: [ECOS] Question on serial ports

> The questions are:
> 
> 1. Does this indeed indicate that a full (not diagnostic) serial port 
> implementation was never completed for the MCB2100 board?
> 
> 2. What was the purpose of the directory 
> ../packages/devs/serial/arm/lpc2xxx/..? Was this just a placeholder 
> for where a device might go?

Take a look at the targets which use this:

target p2106 {
        alias { "Olimex evaluation board LPC-P2106" p2106 }
        packages { CYGPKG_HAL_ARM
                   CYGPKG_HAL_ARM_LPC2XXX
                   CYGPKG_HAL_ARM_LPC2XXX_P2106
                   CYGPKG_IO_SERIAL_GENERIC_16X5X
                   CYGPKG_IO_SERIAL_ARM_LPC2XXX
                   CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX
        }
        description "
        The p2106 target provides the packages needed to run eCos on the
        LPC-P2106 evaluation board from Olimex."
}

target lpcmt {
        alias { "Olimex evaluation board LPC-LPCMT" lpcmt }
        packages { CYGPKG_HAL_ARM
                   CYGPKG_HAL_ARM_LPC2XXX
                   CYGPKG_HAL_ARM_LPC2XXX_LPCMT
                   CYGPKG_IO_SERIAL_GENERIC_16X5X
                   CYGPKG_IO_SERIAL_ARM_LPC2XXX
                   CYGPKG_DEVICES_WATCHDOG_ARM_LPC2XXX
        }
        description "
        The lpcmt target provides the packages needed to run eCos on the
        LPC-LPCMT evaluation board from Olimex."
}

Looking at this suggests that the LPC2XXX serial driver is just what is needed to make the generic 16x5x serial driver work on LPC targets. Take a closer look at one of the these targets and all should become clear...

       Andrew

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Question on serial ports

[Andrew Lunn]

On Fri, Sep 14, 2007 at 05:04:17PM -0400, Scott Moore wrote:
> Hi, sorry to post on this yet again, but I built both
> the p2106 and lpcmt targets, and both appear to have the
> same (forgive me) braindamaged I/O as the mcb2100 board
> target. I tried:
> 
> C:\projects\testbuild>ecosconfig add CYGPKG_IO_SERIAL_GENERIC_16X5X
> Package `CYGPKG_IO_SERIAL_GENERIC_16X5X' is already loaded.
> 
> And the configurator appears to believe that this is already selected.
> However, after building, I don't see the ser_16x5x.o file anywhere
> in the build. ser_16x5x.c is the file 
> ../ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x which
> contains the 16x5x general support. Instead it is including:
> 
> 09/14/2007  01:47 PM            23,264 io_serial_haldiag.o
> 09/14/2007  01:47 PM            26,808 io_serial_serial.o
> 09/14/2007  01:47 PM            21,488 io_serial_tty.o
> 
> haldiag is the package that includes the stripped down, polling
> mode only I/O.
> 
> What's the trick to getting this package (really) included in the
> build?

Do you have CYGPKG_IO_SERIAL_DEVICES enabled? That catches a lot of
people out.

   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

RE: [ECOS] Question on serial ports

[Scott Moore]

That's got it, sorry I missed that.

Thanks so much for the help. 

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch] 
Sent: Friday, September 14, 2007 2:13 PM
To: Scott Moore
Cc: Andrew Lunn; Ecos-Discuss; Steve Gaskill
Subject: Re: [ECOS] Question on serial ports

On Fri, Sep 14, 2007 at 05:04:17PM -0400, Scott Moore wrote:
> Hi, sorry to post on this yet again, but I built both the p2106 and 
> lpcmt targets, and both appear to have the same (forgive me) 
> braindamaged I/O as the mcb2100 board target. I tried:
> 
> C:\projects\testbuild>ecosconfig add CYGPKG_IO_SERIAL_GENERIC_16X5X 
> Package `CYGPKG_IO_SERIAL_GENERIC_16X5X' is already loaded.
> 
> And the configurator appears to believe that this is already selected.
> However, after building, I don't see the ser_16x5x.o file anywhere in 
> the build. ser_16x5x.c is the file 
> ../ecos/packages/devs/serial/generic/16x5x/current/src/ser_16x5x which 
> contains the 16x5x general support. Instead it is including:
> 
> 09/14/2007  01:47 PM            23,264 io_serial_haldiag.o
> 09/14/2007  01:47 PM            26,808 io_serial_serial.o
> 09/14/2007  01:47 PM            21,488 io_serial_tty.o
> 
> haldiag is the package that includes the stripped down, polling mode 
> only I/O.
> 
> What's the trick to getting this package (really) included in the 
> build?

Do you have CYGPKG_IO_SERIAL_DEVICES enabled? That catches a lot of people out.

   Andrew

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
 


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Doug Lea's malloc

[Rick Davis]

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:<Starting malloc4 test>
INFO:<Iteration 0, arenasize=276507344, space free=276507324,
maxfree=276507324>
INFO:<Iteration 10, arenasize=276507344, space free=31489948,
maxfree=29058556>
INFO:<Iteration 20, arenasize=276507344, space free=108284148,
maxfree=58859852>
INFO:<Iteration 30, arenasize=276507344, space free=69580420,
maxfree=65494596>
INFO:<Iteration 40, arenasize=276507344, space free=1714036,
maxfree=1714036>
INFO:<Iteration 50, arenasize=276507344, space free=92251804,
maxfree=38098124>
INFO:<Iteration 60, arenasize=276507344, space free=111664980,
maxfree=58928772>
INFO:<Iteration 70, arenasize=276507344, space free=47689060,
maxfree=36578764>
INFO:<Iteration 80, arenasize=276507344, space free=77573924,
maxfree=77573924>
INFO:<Iteration 90, arenasize=276507344, space free=34070540,
maxfree=23496868>
INFO:<Iteration 100, arenasize=276507344, space free=29280524,
maxfree=29280524>
INFO:<Iteration 110, arenasize=276507344, space free=142085116,
maxfree=100678860>
INFO:<Iteration 120, arenasize=276507344, space free=92516524,
maxfree=39697388>
INFO:<Iteration 130, arenasize=276507344, space free=178518644,
maxfree=110641924>
INFO:<Iteration 140, arenasize=276507344, space free=95249636,
maxfree=95249636>
INFO:<Iteration 150, arenasize=276507344, space free=58732380,
maxfree=31240340>
INFO:<Iteration 160, arenasize=276507344, space free=154251700,
maxfree=109160292>
INFO:<Iteration 170, arenasize=276507344, space free=8964580,
maxfree=5096676>
INFO:<Iteration 180, arenasize=276507344, space free=129668932,
maxfree=106951988>
INFO:<Iteration 190, arenasize=276507344, space free=89131924,
maxfree=89131924>
INFO:<Iteration 200, arenasize=276507344, space free=198999364,
maxfree=140538356>
INFO:<Iteration 203, arenasize=276507344, space free=276507324,
maxfree=276507324>
PASS:<malloc4 test completed successfully>
EXIT:<done>

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

Re: [ECOS] Doug Lea's malloc

[Johan Cederbom]

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:<Starting malloc4 test>
> INFO:<Iteration 0, arenasize=276507344, space free=276507324,
> maxfree=276507324>
> INFO:<Iteration 10, arenasize=276507344, space free=31489948,
> maxfree=29058556>
> INFO:<Iteration 20, arenasize=276507344, space free=108284148,
> maxfree=58859852>
> INFO:<Iteration 30, arenasize=276507344, space free=69580420,
> maxfree=65494596>
> INFO:<Iteration 40, arenasize=276507344, space free=1714036,
> maxfree=1714036>
> INFO:<Iteration 50, arenasize=276507344, space free=92251804,
> maxfree=38098124>
> INFO:<Iteration 60, arenasize=276507344, space free=111664980,
> maxfree=58928772>
> INFO:<Iteration 70, arenasize=276507344, space free=47689060,
> maxfree=36578764>
> INFO:<Iteration 80, arenasize=276507344, space free=77573924,
> maxfree=77573924>
> INFO:<Iteration 90, arenasize=276507344, space free=34070540,
> maxfree=23496868>
> INFO:<Iteration 100, arenasize=276507344, space free=29280524,
> maxfree=29280524>
> INFO:<Iteration 110, arenasize=276507344, space free=142085116,
> maxfree=100678860>
> INFO:<Iteration 120, arenasize=276507344, space free=92516524,
> maxfree=39697388>
> INFO:<Iteration 130, arenasize=276507344, space free=178518644,
> maxfree=110641924>
> INFO:<Iteration 140, arenasize=276507344, space free=95249636,
> maxfree=95249636>
> INFO:<Iteration 150, arenasize=276507344, space free=58732380,
> maxfree=31240340>
> INFO:<Iteration 160, arenasize=276507344, space free=154251700,
> maxfree=109160292>
> INFO:<Iteration 170, arenasize=276507344, space free=8964580,
> maxfree=5096676>
> INFO:<Iteration 180, arenasize=276507344, space free=129668932,
> maxfree=106951988>
> INFO:<Iteration 190, arenasize=276507344, space free=89131924,
> maxfree=89131924>
> INFO:<Iteration 200, arenasize=276507344, space free=198999364,
> maxfree=140538356>
> INFO:<Iteration 203, arenasize=276507344, space free=276507324,
> maxfree=276507324>
> PASS:<malloc4 test completed successfully>
> EXIT:<done>
>
> 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

RE: [ECOS] Doug Lea's malloc

[Rick Davis]

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:<Starting malloc4 test>
> INFO:<Iteration 0, arenasize=276507344, space free=276507324,
> maxfree=276507324>
> INFO:<Iteration 10, arenasize=276507344, space free=31489948,
> maxfree=29058556>
> INFO:<Iteration 20, arenasize=276507344, space free=108284148,
> maxfree=58859852>
> INFO:<Iteration 30, arenasize=276507344, space free=69580420,
> maxfree=65494596>
> INFO:<Iteration 40, arenasize=276507344, space free=1714036,
> maxfree=1714036>
> INFO:<Iteration 50, arenasize=276507344, space free=92251804,
> maxfree=38098124>
> INFO:<Iteration 60, arenasize=276507344, space free=111664980,
> maxfree=58928772>
> INFO:<Iteration 70, arenasize=276507344, space free=47689060,
> maxfree=36578764>
> INFO:<Iteration 80, arenasize=276507344, space free=77573924,
> maxfree=77573924>
> INFO:<Iteration 90, arenasize=276507344, space free=34070540,
> maxfree=23496868>
> INFO:<Iteration 100, arenasize=276507344, space free=29280524,
> maxfree=29280524>
> INFO:<Iteration 110, arenasize=276507344, space free=142085116,
> maxfree=100678860>
> INFO:<Iteration 120, arenasize=276507344, space free=92516524,
> maxfree=39697388>
> INFO:<Iteration 130, arenasize=276507344, space free=178518644,
> maxfree=110641924>
> INFO:<Iteration 140, arenasize=276507344, space free=95249636,
> maxfree=95249636>
> INFO:<Iteration 150, arenasize=276507344, space free=58732380,
> maxfree=31240340>
> INFO:<Iteration 160, arenasize=276507344, space free=154251700,
> maxfree=109160292>
> INFO:<Iteration 170, arenasize=276507344, space free=8964580,
> maxfree=5096676>
> INFO:<Iteration 180, arenasize=276507344, space free=129668932,
> maxfree=106951988>
> INFO:<Iteration 190, arenasize=276507344, space free=89131924,
> maxfree=89131924>
> INFO:<Iteration 200, arenasize=276507344, space free=198999364,
> maxfree=140538356>
> INFO:<Iteration 203, arenasize=276507344, space free=276507324,
> maxfree=276507324>
> PASS:<malloc4 test completed successfully>
> EXIT:<done>
>
> 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