RE: exception access violation

RE: exception access violation

[Cousins, Jeff]

We got the same problem (exception access violation second time round), and
pinned it onto Interfaces.C.Strings.New_String being passed an uninitialised
Ada string, causing the C string allocated to be of some random length,
depending on where/if null was found in the Ada string's memory.
Initialising the Ada string with others => some_non_null_character to force
the C string to be as long as the Ada string was a work-around.

gdb's not as bad as it was.  Several of my colleagues use the DDD GUI
front-end.  We tried the GVD GUI front-end but it was unacceptably slow
starting up, hope to try the new 1.2.4 release soon.



********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

exception access violation

[Jade]

Hi,
I am compiling a program with gnat gps and I am receiving an access
violation error.  And my program crashes at this point.

 Exception raised
 >>> Exception Name        => PROGRAM_ERROR
>>> Exception Message     => EXCEPTION_ACCESS_VIOLATION
Does anyone know what this could mean?  

Thanks,
jade

Re: exception access violation

[Georg Bauhaus]

On Mon, 2006-11-13 at 11:31 -0800, Jade wrote:
> Hi,
> I am compiling a program with gnat gps and I am receiving an access
> violation error.  And my program crashes at this point.
> 
>  Exception raised
>  >>> Exception Name        => PROGRAM_ERROR
> >>> Exception Message     => EXCEPTION_ACCESS_VIOLATION
> Does anyone know what this could mean?  

Could be related to memory access via the operation system, GNAT
experts might be able to tell.
This will be easier to say if you post some code. This excerpt is
from seh_init.c, which you can find in ${GNAT_DIR}/.../adainclude/

  switch (ExceptionRecord->ExceptionCode)
    {
    case EXCEPTION_ACCESS_VIOLATION:
      /* If the failing address isn't maximally-aligned or if the page
         before the faulting page is not accessible, this is a program error.
      */
      if ((ExceptionRecord->ExceptionInformation[1] & 3) != 0
          || IsBadCodePtr
          ((void *)(ExceptionRecord->ExceptionInformation[1] + 4096)))
        {
          exception = &program_error;
          msg = "EXCEPTION_ACCESS_VIOLATION";
        }
      else
        {
          /* otherwise it is a stack overflow  */
          exception = &storage_error;
          msg = "stack overflow (or erroneous memory access)";
        }
      break;



-- Georg 

Re: exception access violation

[Alex R. Mosteo]

Jade wrote:

> Hi,
> I am compiling a program with gnat gps and I am receiving an access
> violation error.  And my program crashes at this point.

I'm not sure if you refer to the compilation crashing or your program
crashing on execution. It seems this latter one.

>  Exception raised
>  >>> Exception Name        => PROGRAM_ERROR
>>>> Exception Message     => EXCEPTION_ACCESS_VIOLATION
> Does anyone know what this could mean?

This is typical of dangling pointers. I.e. you're accessing deallocated
memory. Are you managing some heap memory by hand? If so, I'd suggest using
gdb to get backtraces and/or GNAT.Debug_Pools to aid in the diagnose (if
you're using GNAT obviously) as a first step.

Re: exception access violation

[Jade]

I shuffled around my code and the error is now

Exception Name        => STORAGE_ERROR
 Exception Message     => stack overflow (or erroneous memory access)

I must adjust the stack size either thru gnatbind or gnatlink.  Not
sure what is best.

Jade.

Alex R. Mosteo wrote:
> Jade wrote:
>
> > Hi,
> > I am compiling a program with gnat gps and I am receiving an access
> > violation error.  And my program crashes at this point.
>
> I'm not sure if you refer to the compilation crashing or your program
> crashing on execution. It seems this latter one.
>
> >  Exception raised
> >  >>> Exception Name        => PROGRAM_ERROR
> >>>> Exception Message     => EXCEPTION_ACCESS_VIOLATION
> > Does anyone know what this could mean?
>
> This is typical of dangling pointers. I.e. you're accessing deallocated
> memory. Are you managing some heap memory by hand? If so, I'd suggest using
> gdb to get backtraces and/or GNAT.Debug_Pools to aid in the diagnose (if
> you're using GNAT obviously) as a first step.

Re: exception access violation

[Georg Bauhaus]

On Wed, 2006-11-15 at 10:58 +0100, Alex R. Mosteo wrote:

> However, if you're managing large data structures (over 4MB in size), I'd go
> for a heap-based solution using controlled types. In my experience, abusing
> the stack is a source of headaches sooner or later (specially if you are
> doing something portable).

Why is using the heap + controlled for larger data structures
more portable than using the stack? I know that GNAT needs to
be talked into providing sufficient space on the stack.
You might be that running into this kind of stack trouble only
when you port from another compiler to GNAT?

Should the decision whether some object lives on the heap or on
the stack be based on compilers' support for dynamically sized 
local data structures?

Re: exception access violation

[Alex R. Mosteo]

Jade wrote:

> I shuffled around my code and the error is now
> 
> Exception Name        => STORAGE_ERROR
>  Exception Message     => stack overflow (or erroneous memory access)

Stack size is an OS matter, so you must tell gnatlink the parameters that
will go to the system linker. There are a few threads discussing how to do
this with GNAT that you'll easily find in google groups, at least one is
recent.

However, if you're managing large data structures (over 4MB in size), I'd go
for a heap-based solution using controlled types. In my experience, abusing
the stack is a source of headaches sooner or later (specially if you are
doing something portable).

Note that ill-managed recursivity can also be a source of stack overflows,
and you can check this in GNAT with -fstack-check. Without it, stack
overflows are sometimes reported as violations instead.

Regards, Alex.

Re: exception access violation

[Alex R. Mosteo]

Georg Bauhaus wrote:

> Why is using the heap + controlled for larger data structures
> more portable than using the stack? I know that GNAT needs to
> be talked into providing sufficient space on the stack.
> You might be that running into this kind of stack trouble only
> when you port from another compiler to GNAT?

I have no experiences out of GNAT, that be said first.

In past times, I had to deal with implicit limits in Linux/ld (I seem to
remember it was 2MB. This has changed with kernels and is no longer an
issue). Because of this, porting from Windows to Linux was somewhat painful
because problems not arising in Windows did arise in Linux (even using the
usual linker stack options, so I had to dig for even more obscure
switches). Other languages don't exploit so much the stack, so it is more
difficult to find experiences in the area from other developers.

Other point that may be relevant: by default, gnat doesn't release memory
historically claimed by stacks, contrarily to heap-allocated one. Couple
this with lots of tasks or recursivity and quickly memory can start to be
an issue. (I'm not sure if this is linux 2.6 default behavior or gnat
management of secondary stacks, couldn't locate it in the docs).

Finally is the trap I always fall for: "This is small enough to be in the
stack". And then it grows, and then it starts to be a problem, or some
recursive algorithm can't recurse enough, and you end changing it or having
humongous stacks or reworking algorithms.

Of course, in realtime environments you'll prefer to know your memory needs
from the start.

> Should the decision whether some object lives on the heap or on
> the stack be based on compilers' support for dynamically sized
> local data structures?

As long as compilers are not perfect, I suppose it is at least an extra
factor to consider. Also, I'd not limit it only to dynamically sized data.

I've been bitten several times by stack-related problems when using GNAT,
that's all I wanted to transmit (hence the 'in my experience' remark). If
you don't have desires to learn about system internals, GNAT
primary/secondary stacks and so... use the heap, luke ;)

It is worrysome that I'm saying all this, because I find much more
comfortable using the stack than any heap management.

Re: exception access violation

[Kevin K]

On Wed, 15 Nov 2006 09:52:10 UTC, Georg Bauhaus 
<bauhaus@futureapps.de> wrote:

> Why is using the heap + controlled for larger data structures
> more portable than using the stack? I


Some operating systems put smaller than you would expect limitations 
on the environment stack.  And while you can change it in some cases, 
while playing around, I found that Mac OSX, for example, seemed to 
have a 16MB limit (going by memory).  And since task stacks were put 
on this stack instead of in the heap, that further limited it.  If I 
was writing stuff from scratch that was also going to run on it, I 
would work on putting the data on the heap.

-- 

Exception_Access_Violation

[mhamel_98]

Looking for some pointers (!!!) here.  I'm getting the above
program_error message when trying to free some pointers.  The context
is a double linked list which uses a storage manager to allocate
chunks of nodes at a time.  I have an option on Clear to either keep
the pool intact for later use, or to deallocate when desired.  When
deallocating, I'm using an instantiated unchecked_deallocation, it
gets part way through the list, then pops out the program error.  The
pointers are being checked for nullness and I've looked at the
addresses and the look "ok".  Any tips on what else to look for?

Re: Exception_Access_Violation

[John B. Matthews]

In article 
<3f465d87-0fc9-415d-a60b-72a0d744dce1@h23g2000vbc.googlegroups.com>,
 mhamel_98@yahoo.com wrote:

> Looking for some pointers (!!!) here.  I'm getting the above
> program_error message when trying to free some pointers.  The context
> is a double linked list which uses a storage manager to allocate
> chunks of nodes at a time.  I have an option on Clear to either keep
> the pool intact for later use, or to deallocate when desired.  When
> deallocating, I'm using an instantiated unchecked_deallocation, it
> gets part way through the list, then pops out the program error.  The
> pointers are being checked for nullness and I've looked at the
> addresses and the look "ok".  Any tips on what else to look for?

Any chance the problem pointer is a copy of a previously (and 
successfully) deallocated node?

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Exception_Access_Violation

[Alex R. Mosteo]

John B. Matthews wrote:

> In article
> <3f465d87-0fc9-415d-a60b-72a0d744dce1@h23g2000vbc.googlegroups.com>,
>  mhamel_98@yahoo.com wrote:
> 
>> Looking for some pointers (!!!) here.  I'm getting the above
>> program_error message when trying to free some pointers.  The context
>> is a double linked list which uses a storage manager to allocate
>> chunks of nodes at a time.  I have an option on Clear to either keep
>> the pool intact for later use, or to deallocate when desired.  When
>> deallocating, I'm using an instantiated unchecked_deallocation, it
>> gets part way through the list, then pops out the program error.  The
>> pointers are being checked for nullness and I've looked at the
>> addresses and the look "ok".  Any tips on what else to look for?
> 
> Any chance the problem pointer is a copy of a previously (and
> successfully) deallocated node?

It looks like that to me too. 

If the error resists. and you're using GNAT, you can try with 
Gnat.Debug_Pools. 
Or Valgrind in any case.

Re: Exception_Access_Violation

[mhamel_98]

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.

Re: Exception_Access_Violation

[Björn Persson]

mhamel_98@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.

When you have allocated an array you must also deallocate it as an array.
You can't deallocate individual elements of an array.

-- 
Bj�rn Persson
PGP key A88682FD

Re: Exception_Access_Violation

[Niklas Holsti]

Bj�rn Persson wrote:
> mhamel_98@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.
> 
> 
> When you have allocated an array you must also deallocate it as an array.
> You can't deallocate individual elements of an array.

Just to add to Bj�rn's comment: If you have an indexed collection 
of nodes, and want to deallocate nodes at some indices without 
deallocating them all at once, you can make an array of access values.

For example:

    type Node is ...
    type Node_Ref is access Node;
    procedure Deallocate is new Unchecked_Deallocation (...)

    Collection : array (1 .. 100) of Node_Ref:

Now you can do:

    Collection(5) := new Node;

Collection(5) now contains an access to a new Node. Later you can do:

    Deallocate (Collection(5));

The new node is now deallocated and Collection(5) is null.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Exception_Access_Violation

[Adam Beneschan]

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