Weird bug - Protected object - Gnat 3.15p win32

Weird bug - Protected object - Gnat 3.15p win32

[Jano]

Hi Ada men,

I think I've stumbled across another mortifying bug 
in gnat 3.15p win32, another one which has taken a lot 
of time to track down. Please share any knowledge you 
have about it:

The thing is that I have a protected type with a lot
of functions and quite some encapsulated data. Sud-
denly it has started to cause deadlocks. After any call
to a function (not procedure!) in the protected type, the
lock of the monitor is not released for some reason, 
because any subsequent call to the object will lock and
not enter it. The function can have null body, no other
tasks are using the protected object.

After tinkering around, I've detected that changing the
following private member declaration makes the deadlock
to go away:

protected type Blah is
   -- procedures and functions
private

   Some_Array : Array_Type (1 .. 1); 
      -- Will work ok
   Some_Array : Array_Type (1 .. Global_Variable); 
      -- Will deadlock

end Blah;

Note that Global_Variable also equals to 1!

I've tried to get a small reproducer using new code, but
failed, so there must be some other dependences for it 
to arise. Using the code from the project where I've detected
it, it happens for every instance of the protected type.

Someone has noticed something like this?

Having been bitten hard at least twice by gnat bugs in 
3.15p win, I'm thinking of making a bugs page for other 
people to be warned ahead. I'm already aware of the 
following:

* The broken time packages.
* The broken Select in Gnat.Sockets.

If you're aware of such kind of bugs which are hard to 
detect and track down, please write about them so I can
collect them for reference. I think it can spare useful
time to newcomers.

Thanks!

Re: Weird bug - Protected object - Gnat 3.15p win32

[Ludovic Brenta]

Jano writes:
> I've tried to get a small reproducer using new code, but failed, so
> there must be some other dependences for it to arise. Using the code
> from the project where I've detected it, it happens for every
> instance of the protected type.

I would be very interested in such a reproducer.

> Having been bitten hard at least twice by gnat bugs in 3.15p win,
> I'm thinking of making a bugs page for other people to be warned
> ahead. I'm already aware of the following:
>
> * The broken time packages.
> * The broken Select in Gnat.Sockets.
>
> If you're aware of such kind of bugs which are hard to detect and
> track down, please write about them so I can collect them for
> reference. I think it can spare useful time to newcomers.

There already exists such a central place; it is called the Debian bug
tracking system.  If your bug is not specific to Windows, I encourage
you to submit it there:

http://bugs.debian.org

The following URL lists all bugs that are currently known in GNAT:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=gnat

I have already backported several fixes into the Debian package for
GNAT (including one in package GNAT.Sockets; it may be the one you
referred to).

I also have a test suite that I use to reproduce all bugs and verify
fixes.

-- 
Ludovic Brenta.

Re: Weird bug - Protected object - Gnat 3.15p win32

[Jano]

Ludovic Brenta wrote:
> Jano writes:
> 
>>I've tried to get a small reproducer using new code, but failed, so
>>there must be some other dependences for it to arise. Using the code
>>from the project where I've detected it, it happens for every
>>instance of the protected type.
> 
> 
> I would be very interested in such a reproducer.

I'll try to produce a minimal set of files needed to trigger it.

>>Having been bitten hard at least twice by gnat bugs in 3.15p win,
>>I'm thinking of making a bugs page for other people to be warned
>>ahead. I'm already aware of the following:
>>
>>* The broken time packages.
>>* The broken Select in Gnat.Sockets.
>>
>>If you're aware of such kind of bugs which are hard to detect and
>>track down, please write about them so I can collect them for
>>reference. I think it can spare useful time to newcomers.
> 
> 
> There already exists such a central place; it is called the Debian bug
> tracking system.  If your bug is not specific to Windows, I encourage
> you to submit it there:
> 
> http://bugs.debian.org
> 
> The following URL lists all bugs that are currently known in GNAT:
> 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=gnat

Very interesting. Sadly I assume the windows specific bugs aren't there. 
  BTW, if you're familiar with linux maybe you can answer this:

I've been unsuccesful trying to set a task stack size above 2 MB in 
linux. Gnat accepts the pragma but doesn't obey it, ulimits are removed, 
--X linker switches seem ignored too. I seem to remember from when I 
looked at it that it is some limitation in ld. Would such a thing, if 
true, qualify as a bug?

Best regards,

Alex.

Re: Weird bug - Protected object - Gnat 3.15p win32

[Jeffrey Carter]

Jano wrote:

> The thing is that I have a protected type with a lot
> of functions and quite some encapsulated data. Sud-
> denly it has started to cause deadlocks. After any call
> to a function (not procedure!) in the protected type, the
> lock of the monitor is not released for some reason, 
> because any subsequent call to the object will lock and
> not enter it. The function can have null body, no other
> tasks are using the protected object.

If a function has a null body, it will raise Program_Error. Is it 
possible that what you are seeing is the result of this exception, and 
tasks perhaps dying silently as a result?

> protected type Blah is
>    -- procedures and functions
> private
> 
>    Some_Array : Array_Type (1 .. 1); 
>       -- Will work ok
>    Some_Array : Array_Type (1 .. Global_Variable); 
>       -- Will deadlock
> 
> end Blah;
> 
> Note that Global_Variable also equals to 1!

If Global_Variable changes after this type declaration is elaborated, 
using Global_Variable to index Some_Array will raise Constraint_Error, 
with similar effects to raising Program_Error.

> I've tried to get a small reproducer using new code, but
> failed, so there must be some other dependences for it 
> to arise. Using the code from the project where I've detected
> it, it happens for every instance of the protected type.

Without complete code that compiles and produces the problem, it's 
difficult to tell if this is a problem with GNAT or your code. The fact 
that you're having difficulty reproducing the problem means the latter 
is more likely.

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: Weird bug - Protected object - Gnat 3.15p win32

[Jano]

Jeffrey Carter wrote:
> Jano wrote:
> 
>> The thing is that I have a protected type with a lot
>> of functions and quite some encapsulated data. Sud-
>> denly it has started to cause deadlocks. After any call
>> to a function (not procedure!) in the protected type, the
>> lock of the monitor is not released for some reason, because any 
>> subsequent call to the object will lock and
>> not enter it. The function can have null body, no other
>> tasks are using the protected object.
> 
> 
> If a function has a null body, it will raise Program_Error. Is it 
> possible that what you are seeing is the result of this exception, and 
> tasks perhaps dying silently as a result?

I'm aware, my fault. It was a simplification, the funcion returns a 
natural, it's body is simply "return 0;"

BTW triggering an exception in the function and catching it outside 
gives the same result.

> 
>> protected type Blah is
>>    -- procedures and functions
>> private
>>
>>    Some_Array : Array_Type (1 .. 1);       -- Will work ok
>>    Some_Array : Array_Type (1 .. Global_Variable);       -- Will deadlock
>>
>> end Blah;
>>
>> Note that Global_Variable also equals to 1!
> 
> 
> If Global_Variable changes after this type declaration is elaborated, 
> using Global_Variable to index Some_Array will raise Constraint_Error, 
> with similar effects to raising Program_Error.

The variable doesn't change, I'm not accesing that array neither in my 
tests.

>> I've tried to get a small reproducer using new code, but
>> failed, so there must be some other dependences for it to arise. Using 
>> the code from the project where I've detected
>> it, it happens for every instance of the protected type.
> 
> 
> Without complete code that compiles and produces the problem, it's 
> difficult to tell if this is a problem with GNAT or your code. The fact 
> that you're having difficulty reproducing the problem means the latter 
> is more likely.

I'm working on producing it, and I'm generally in agreement with you 
that the probable cause is some bug on my part. I used to be of the 
oppinion that compilers never produce funny behavior, even if everything 
points that way. However, after the realtime clock affair I'm kinda 
"burned". In that occasion, after much head smashing I asked here and it 
was a well known problem but I had never heard of it, so now I'm more 
prone to ask before a 100% proof just in case it can save me useful 
time. It's the problem of not being rich enough to be a supported 
AdaCore customer ;)

Anyway, before asking I always try to be as sure as possible that 
there's no bug in my part causing this:

* The protected object is afresh, not used in any other task/code.
* GBD stack traces show no other thread inside the protected object.
* Using a controlled type tracing entrances/exits of all methods of the 
type shows only a single entrance/exit and then the lock happens.

For now, I can only believe in a gnat bug or some other task 
overwritting the memory containing the lock. The latter seems unlikely 
because the first call always succedd, and no other erratic behavior 
happens. No known memory leaks, dangling pointers, unexpected protection 
faults... However the project is big and that worries me reasonably, I 
can't easily prevent some elaboration. But then, I've tried too with a 
heap-allocated instance and the same happens.

In the end, I could be wrong and have discovered Yet Another Way of 
Blaming the Compiler(tm) for an Own Bug ;) but I'll try to get a 
reproducer which could clean my honor ;)))

Best regards,

Alex.

Re: Weird bug - Protected object - Gnat 3.15p win32

[Nick Roberts]

On Mon, 12 Jul 2004 10:57:55 +0200, Jano <notelacreas@porfavor.no> wrote:

> ...
> In the end, I could be wrong and have discovered Yet Another
> Way of Blaming the Compiler(tm) for an Own Bug ;)

LOL

> but I'll try to get a reproducer which could clean my
> honor ;)))

One suggestion that just might help you pin it down (to the compiler) is  
to get GNAT/GCC to produce an assembly listing. I think the relevant  
switch is '-S' (big S) to gcc, or '-gS' to gnatmake (but Don't Quote Me On  
That[TM] ;-)

-- 
Nick Roberts

Re: Weird bug - Protected object - Gnat 3.15p win32

[Jano]

Nick Roberts wrote:
> On Mon, 12 Jul 2004 10:57:55 +0200, Jano <notelacreas@porfavor.no> wrote:
> 
>> ...
>> In the end, I could be wrong and have discovered Yet Another
>> Way of Blaming the Compiler(tm) for an Own Bug ;)
> 
> 
> LOL
> 
>> but I'll try to get a reproducer which could clean my
>> honor ;)))
> 
> 
> One suggestion that just might help you pin it down (to the compiler) 
> is  to get GNAT/GCC to produce an assembly listing. I think the 
> relevant  switch is '-S' (big S) to gcc, or '-gS' to gnatmake (but Don't 
> Quote Me On  That[TM] ;-)

Been there... done that... sadly I must confess that so many years far 
from assembler have weakened my skills. At first I thought it would be 
easy to inspect the locking mechanism... maybe I'll try again when moral 
goes up.

Re: Weird bug - Protected object - Gnat 3.15p win32

[Nick Roberts]

On Mon, 12 Jul 2004 18:37:41 +0200, Jano <notelacreas@porfavor.no> wrote:

> Been there... done that... sadly I must confess that so many years far  
> from assembler have weakened my skills. At first I thought it would be  
> easy to inspect the locking mechanism... maybe I'll try again when moral  
> goes up.

Yes I understand! Those pages of impenetrable movs do make the brain ache.  
The phrase 'needle in a haystack' is most apt.

-- 
Nick Roberts

Re: Weird bug - Protected object - Gnat 3.15p win32

[Jeffrey Carter]

Jano wrote:

> Been there... done that... sadly I must confess that so many years far 
> from assembler have weakened my skills. At first I thought it would be 
> easy to inspect the locking mechanism... maybe I'll try again when moral 
> goes up.

You might take a look at the -gnatG switch. It produces pseudocode that 
is lower level than Ada, but higher than assembler.

-- 
Jeff Carter
"To err is human, to really screw up, you need C++!"
St�phane Richard
63

Re: Weird bug - Protected object - Gnat 3.15p win32

[Jano]

Jeffrey Carter wrote:
> Jano wrote:
> 
>> Been there... done that... sadly I must confess that so many years far 
>> from assembler have weakened my skills. At first I thought it would be 
>> easy to inspect the locking mechanism... maybe I'll try again when 
>> moral goes up.
> 
> 
> You might take a look at the -gnatG switch. It produces pseudocode that 
> is lower level than Ada, but higher than assembler.

I'll do, thanks.