Date: Thu, 13 Aug 1998 02:46:10 +0000 ( ) From: "Gurunandan R. Bhat" To: Eli Zaretskii Cc: djgpp-workers AT delorie DOT com Subject: Re: [grbhat AT unigoa DOT ernet DOT in: Problem with process_coff()] In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 12 Aug 1998, Eli Zaretskii wrote: > The natural question here would be: does FSDB crash exactly for such > cases of ``the last function''? If it does, then fixing this will > prevent it from crashing; if not, there's one more bug ;-). Yes. In all the cases that I have checked, malloc's tables are corrupted after the last line number entry is read. There are fortuitous circumstances however, when the space above the malloc'ed array is filled with zeros. Then the crash goes away. > Again, the natural question would be: what is the situation with this > aspect when FSDB crashes for you? Or does it crash on any kind of > program, -g or not -g alike? On both kinds. > > > lbase = -1 may be used as > > a flag to stop processing for line numbers > Seems like a good idea to include such a change anyway. It cannot > possibly hurt, can it? Not to the best of my limited understanding. But as DJ says, the symbol table is one of the most complex structures, and I would wait untill someone with deeper understanding than mine rules on this. For the moment, I know how to get around this in a way that has not proved counterproductive. > > As expected (since this is the symbol whose line number > > entry is last), mallocs tables get corrupted exactly after process_coff > > reads this module. > > So it seems we need either some method of detecting the last l[] element, > or just terminate the loop when lbase becomes negative, or both. The first IMHO is safer, only because I do not yet understand the intricacies of the auxillary entry, on which lbase depends. Thank you and with warmest regards Gurunandan