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

[Jano <notelacreas@porfavor.no>]

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.