comp.lang.ada
 help / color / mirror / Atom feed
From: Adam Beneschan <adam@irvine.com>
Subject: Re: Exception_Access_Violation
Date: Fri, 22 May 2009 09:38:07 -0700 (PDT)
Date: 2009-05-22T09:38:07-07:00	[thread overview]
Message-ID: <de1245a7-4951-492c-b120-dcd1673a7312@s1g2000prd.googlegroups.com> (raw)
In-Reply-To: 669e505c-f111-47b9-8cc5-ca1815161c53@s20g2000vbp.googlegroups.com

On May 20, 8:30 am, mhamel...@yahoo.com wrote:
> Problem solved!  Thanks for all the help, especially the pointer to
> Debug_Pools.  The problem was that instead of allocating one node at a
> time, I was allocating an array of nodes at once.  Deallocating nodes
> allocated from an array allocation is apparently bad juju.  I don't
> understand it, but can work around it.

The Ada language rules say that you cannot call Unchecked_Deallocation
on something that has not been allocated with "new".  This isn't any
different from other languages.  In C, for example, the man page for
free() says "free()  frees  the  memory  space pointed to by ptr,
which must have been returned by a previous  call  to  malloc(), calloc
()  or  realloc()."  In other words, you can't just "deallocate" any
chunk of memory you feel like; it has to be an area of memory that was
previously allocated by the storage manager---the whole thing, not
some part of it.  The simple reason for this is that the storage
manager that handles allocations and deallocations expects things to
be done this way, and it may keep information about the memory areas
that have been allocated, or close to the memory areas.  For example,
when you allocate a block of memory, the storage manager may reserve a
couple words just *below* that block of memory to keep its own control
information.  (It won't necessarily do this, but it might.)  Trying to
deallocate something that the storage manager doesn't know about, or
trying to deallocate something that has already been deallocating, is
about the worst thing you can do.  It is likely to screw up the
storage manager's data structures, and often will lead to bugs in the
program that won't be detected until much later in the execution, and
bugs like that are the most difficult ones to track down---trust me,
I've been there, especially back when I was working in C.  So don't
mess with it.

If you really want to reuse individual nodes, you probably want to
write your own deallocation and allocation routines for nodes, instead
of relying on Unchecked_Deallocation and "new".  The deallocation
routine would add a node to a free list; the allocation routine would
then reuse a node from the free list if there are any.

                                    -- Adam





  parent reply	other threads:[~2009-05-22 16:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-18 16:05 Exception_Access_Violation mhamel_98
2009-05-18 16:14 ` Exception_Access_Violation John B. Matthews
2009-05-19  7:23   ` Exception_Access_Violation Alex R. Mosteo
2009-05-20 15:30     ` Exception_Access_Violation mhamel_98
2009-05-22 14:34       ` Exception_Access_Violation Björn Persson
2009-05-22 15:17         ` Exception_Access_Violation Niklas Holsti
2009-05-22 16:38       ` Adam Beneschan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-11-13 19:31 exception access violation Jade
2006-11-13 21:35 ` Georg Bauhaus
2006-11-14  9:09 ` Alex R. Mosteo
2006-11-14 19:34   ` Jade
2006-11-15  9:58     ` Alex R. Mosteo
2006-11-15  9:52       ` Georg Bauhaus
2006-11-15 13:32         ` Alex R. Mosteo
2006-11-15 23:43         ` Kevin K
2001-12-07 12:41 Cousins, Jeff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox