This is the mail archive of the ecos-bugs@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 20269] New: assertion failed in Cyg_Mempool_fixed_Implementation


http://bugs.ecos.sourceware.org/show_bug.cgi?id=20269

           Summary: assertion failed in Cyg_Mempool_fixed_Implementation
           Product: eCos
           Version: 1.2.1
          Platform: All
        OS/Version: All
            Status: ASSIGNED
          Severity: critical
          Priority: low
         Component: Memory allocators
        AssignedTo: jifl at ecoscentric dot com
        ReportedBy: anonymous at egcs dot cygnus dot com
                CC: andrew dot lunn at ascom dot ch


The fixed size pool facility has a few 'features' that are not
documented. 

1) You have to allocate more memory than you think because the
implementation steals some for its internal use. Which should at
least be documented, and prefereably not happen since its hard to
know how much extra memory should be allocated since it depends
on a few factors. This is also bad in that it could block when
you don't expect it to.

Suggested solution: Provide a function that calculates the amount
of extra memory required for the internal admin. 


2) A result of 1) is that you cannot allocate a memory pool of
zero or one element. This makes it harder to dynamically set the
size of the pool at creation time using a calculation of the
number of elements required. This is also not documented. 


---------------------------------------------------------------------------

Originator:
Andrew Lunn

Organization:
ASCOM Systec

Audit-Trail:
Responsible-Changed-From-To: alexs->jlarmour 
Responsible-Changed-By: alexs 
Responsible-Changed-When: Wed Jul 7 02:26:03 PDT 1999 
Responsible-Changed-Why:  
Hi Jifl 

Seems Ascom have picked up on something.  Could you please look into 
this and provide Robert with any additional and relevant documentation? 

Thanks 
-- Alex 


From: Jonathan Larmour <jlarmour at cygnus dot co dot uk>
To: andrew dot lunn at ascom dot ch
Cc: bugs at cygnus dot com, Robert Erskine <roberte at cygnus dot co dot uk>
Subject: Re: ecos/20269 [assertion failed in Cyg_Mempool_fixed_Implementation]
Date: Fri, 09 Jul 1999 19:07:55 +0000

 Hello again Andrew :-),
 
 > The fixed size pool facility has a few 'features' that are not
 > documented.
 > 
 > 1) You have to allocate more memory than you think because the
 > implementation steals some for its internal use. Which should at
 > least be documented, and prefereably not happen since its hard to
 > know how much extra memory should be allocated since it depends
 > on a few factors. This is also bad in that it could block when
 > you don't expect it to.
 
 Yes, we should emphasise this, but this is a very common aspect of memory
 allocators, so I wouldn't think it would surprise too many people.
 
 > Suggested solution: Provide a function that calculates the amount
 > of extra memory required for the internal admin.
 
 We hope to clean up the APIs at some point to make it a completely generic
 memory allocator interface. Such a function would not make sense for most
 variable block allocators.
 
 May I suggest instead that it would be simpler to document this, rather than
 muddying the API. For this particular implementation, the overhead is
 related to the "size" and "blocksize" fields supplied to
 cyg_mempool_fix_create().
 
 The extra space overhead to reserve (in bytes) can be determined by the
 following expression:
 
 ((((desired_size/blocksize) + 31) >> 5) << 2)
 
 The two shifts can't be consolidated since we want truncation.
 
 > 2) A result of 1) is that you cannot allocate a memory pool of
 > zero or one element. This makes it harder to dynamically set the
 > size of the pool at creation time using a calculation of the
 > number of elements required. This is also not documented.
 
 Yes, I think we should change that. I'll see about getting this into the
 beta to be delivered to you at the end of the month. Unless you need this
 sooner?
 
 Jifl
 -- 
 Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
 "I used to have an open mind but || Get yer free open source RTOS's here...
  my brains kept falling out."    || http://sourceware.cygnus.com/ecos
 Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Unformatted:
Originator:  

page: sourceware.cygnus.com/ecos/problemreport.html

Send_PR_form: Sent_from_sourceware.cygnus.com



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]