From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,fc4ac82d0abec4ff X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Jano Newsgroups: comp.lang.ada Subject: Re: Weird bug - Protected object - Gnat 3.15p win32 Date: Mon, 12 Jul 2004 10:57:55 +0200 Message-ID: <2lf23oFbf1vfU1@uni-berlin.de> References: <5d6fdb61.0407110729.657570af@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 5Uzj7c/Eizy+65B2+bcIMQuiutUc73/l4Zr/dIHfMDW9jDTgE= User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:2151 Date: 2004-07-12T10:57:55+02:00 List-Id: 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.