Re: problem solved (and now I know why)

Re: problem solved (and now I know why)

[Stephen Arnold]

Well, I've learned alot today :)

Thanks to some help from Julian Day (what is your real name anyway?) I
figured out my problem (but there's still a problem on the windoze
platform...)

In my original Remove procedure, I had a call to Clear to clear the list
when it only contained a single element.  However, after Clear freed the
memory for the single list element, and set the list pointers to null,
it jumped back to Remove, which tried to free the same memory.  Again
(not good).  So now, with 20-20 hindsight, it's obvious why my code
barfed on Linux.  That's exactly what it *should've* done.

However, one question remains:  Why did windoze not catch this problem? 
My original (and incorrect) code runs just fine on win95, win98, and
even NT4 (which my instructor uses).  The original code passed his test
driver with flying colors, and he tests *everything* (including the
Overflow exception).

Is there any way for GNAT to catch this at run-time, or is it completely
up to the OS?  I guess I'll be sticking to Linux from now on...

Thanks, Steve

problem solved, but I don't know why (was: GNAT implementation bug)

[Steve Arnold]

It looks like I solved the problem, but I still have no idea why there was a 
problem in the first place (being a newbie, it seems like it *should've* 
worked).

When I replaced the following (in Remove):

       if List.Count = 1 then
          Clear(List) ;
       elsif List.Cursor = List.Head then...

with the actual code from Clear:

       if List.Count = 1 then
          List := (Count => 0, Traversing => False, others => null) ;
       elsif List.Cursor = List.Head then...

it started working correctly.  But I still have at least two questions (on 
this particular issue, anyway ;)

1) Why did this code behave differently when running under Linux than when 
running under windoze?  (obvious answer: windoze is brain-dead)

2) Why did my trivial change fix it?

In other parts of these packages, I call functions/procedures that were 
defined in the same package, and it always worked.  For example, I do this:

   begin -- Remove
       if List.Count = 0 then
          Ada.Exceptions.Raise_Exception (Cursor_Error'identity,...

which should always work.  But I also do this (which seems more readable to 
me):

      elsif Empty(List) then
         Ada.Exceptions.Raise_Exception (Cursor_Error'identity,...

where function Empty is in the same package as Remove, Clear, etc, and this 
also works (at least it seems to).  Am I doing something wrong?  Is there only 
a potential problem doing this when the called function/procedure is 
manipulating pointers?  Just what is going on here?  When is it safe to do 
this (if ever) and when is it not safe?

Re: problem solved, but I don't know why (was: GNAT implementation bug)

[Tucker Taft]

Steve Arnold wrote:
> 
> It looks like I solved the problem, but I still have no idea why there was a
> problem in the first place (being a newbie, it seems like it *should've*
> worked).
> 
> When I replaced the following (in Remove):
> 
>        if List.Count = 1 then
>           Clear(List) ;
>        elsif List.Cursor = List.Head then...
> 
> with the actual code from Clear:
> 
>        if List.Count = 1 then
>           List := (Count => 0, Traversing => False, others => null) ;
>        elsif List.Cursor = List.Head then...
> 
> it started working correctly.  But I still have at least two questions (on
> this particular issue, anyway ;)
> 
> 1) Why did this code behave differently when running under Linux than when
> running under windoze?  (obvious answer: windoze is brain-dead)

It could be a bug in the gcc back end for Linux, or it
could be a problem with a small default stack size.

> 
> 2) Why did my trivial change fix it?

You "hand-inlined" one function, which conceivably might lessen
the stack requirements.  Or it is a codegenerator bug, and you
made a small change which happened to eliminate the combination
of constructs which hit the latent bug.

> 
> In other parts of these packages, I call functions/procedures that were
> defined in the same package, and it always worked...

It sounds like a bug in the run-time system, the code generator,
or a too-small default stack size.  I wouldn't try to figure
out what *you* did wrong.  It is probably someone else's fault.

> ... Just what is going on here?  When is it safe to do
> this (if ever) and when is it not safe?

You seem to have been unlucky enough to bump into a compiler or run-time
bug.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: problem solved, but I don't know why (was: GNAT implementation bug)

[Robert Dewar]

In article <38F79277.84A3262E@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> You seem to have been unlucky enough to bump into a compiler
> or run-time bug.


Sorry, I don't see any evidence at all here of any bug in the
compiler or the run time.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: problem solved (and now I know why)

[Florian Weimer]

Stephen Arnold <arnold.steve@ensco.com> writes:

> However, one question remains:  Why did windoze not catch this problem? 
> My original (and incorrect) code runs just fine on win95, win98, and
> even NT4 (which my instructor uses).  The original code passed his test
> driver with flying colors, and he tests *everything* (including the
> Overflow exception).

Your program was erroneous, which means that anything could have
happened.

> Is there any way for GNAT to catch this at run-time, or is it completely
> up to the OS?  I guess I'll be sticking to Linux from now on...

I think there are Windows libraries with a special version of malloc()
which detects such errors.  I don't know how to use them with GNAT,
though.