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,fb264cdd67c2f20f X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ... References: <05lkrrojfd.fsf@hod.lan.m-e-leypold.de> <16veqny46o.fsf_-_@hod.lan.m-e-leypold.de> <4gdbbqF1ld2nsU1@individual.net> <1151890699.675297.250220@m79g2000cwm.googlegroups.com> From: M E Leypold Date: 03 Jul 2006 12:36:34 +0200 Message-ID: <27y7vbkma5.fsf@hod.lan.m-e-leypold.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Some cool user agent (SCUG) NNTP-Posting-Host: 88.72.219.12 X-Trace: news.arcor-ip.de 1151922600 88.72.219.12 (3 Jul 2006 12:30:00 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news2.google.com!news.germany.com!news.tu-darmstadt.de!newsfeed.hanau.net!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:5459 Date: 2006-07-03T12:36:34+02:00 List-Id: "Steve Whalen" writes: > So maybe 3.15p does NOT actually blow up, so much as abuse memory in > some way that evidences different outcomes depending on the > environment. Exactly. I've done experiments when the finalizers and initializers in the variant parts run (by defining a controlled type and writing "Hi, I'am Finalizer A" to standard output) and it seems to depend on the phase of the moon which finalizers are run: - Sometimes no initializers / finalizers are run during read. - Sometimes finalizers are run that shouldn't (finalizers on both variant parts are run) - Sometimes simply the wrong finalizers are run (I observed that on block exit) The dependency is on the whole circumstances surrounding a call to read or the exact layout of the record structure. Once compiled, everything is absolutely repeatably, but adding dummy fields and changing procedure call sequences, even inserting additional statements somewhere around the call to read seems to change something sometimes. The best thing I had, was that when printing the discriminant after input it was some value X which should have resulted in the finalizer of some variant part B being run. Input was completely OK from that point of view. But on leaving the block, the finalizer for the other part A was run. Of course if B does now contain a bit pattern which is not a pointer to some block on the heap and the finalizer to A does try to deallocate that as a pointer things start disintegrate. (And since with libc malloc you can often AFAIR free invalid pointers which is OK for some time but introduces a defect in the heap managament structures, the symptoms will perhaps only turn up muuuuch later when on tries to malloc() something different elsewhere.) I suspected (and still suspect) some problem with the analysis of the flow of values during code generation. In the last case the old value of the discriminant would be cached somewhere and used to determine the action (finalizer to be run) on block exit. I admit on reading tea leaves here since I'm not really an expert on this issues. I'd tried to turn optimization of, hoping that would somehow since it would change optimization: It didn't. It would certainly be instructive to examine the generated code and see where the corruption occurs (I also wouldn't completely exclude the possibily that this is just a memory problem, as you said, perhaps even in the libc or the way the libc works with the Gnat runtime, signals and tasking: For all I know it could be race condition in libc malloc()). I'll postpone that for a while, since understanding this won't fix it and other priorities are higher now. Still wanted to record my thoughts on that issue. > Dmitry's idiom may help, but I thought I'd report this, since it looks Unfortunately it doesn't. Not in the big picture. It just seems to happen to suppress illegal invocation of some finalizers in the test cases, so everything seems to be fine, but with another and more complicated record layout the error comes back. It's really a Heisenbug. :-). > to me like there may only be one problem, and that's a memory problem > in the "read" phase that just causes different symptoms. Since I tracked which finalizers are run (or at least tried) my suspicion is, that it is a memory problem caused by running the wrong finalizer at the wrong time. Regards -- Markus