X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Mon, 23 Apr 2001 15:03:51 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp workers list cc: n_abing AT ns DOT roxas-online DOT net DOT ph Subject: Re: Fixed core dumper in dpmiexcp.c In-Reply-To: <4634-Sat21Apr2001212942+0300-eliz@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, 21 Apr 2001, Eli Zaretskii wrote: [...] > > with InnoculateIT PE 5.2.9.0 active. To be more precise: it crashed until > > I disabled the "Heuristic" option in the option dialog for online > > scanning. > > Do you have an idea what does that option cause InnoculateIT to do? No. But some further testing this weekend revealed even more strange behaviour. The most curious one I observed was with two DOS boxes open, in Win98 (one with DJGPP environment set up, the other a plain DOS shell, but that's not an important detail, I think). Running the test program in one of the shells crashed (SIGSEGV, coredump progress level reported to be 11), but *only* iff another DOS shell was open. I.e. closing the other DOS window, the test program successfully dumped a correct core, opening the other window again and repeating the test in the first window caused it to crash, again. All the while, running the test in the _other_ window worked fine. I then went on and investigated a bit further. I found that switching to Unixy sbrk() algorithm via the crt0 startup flag fixed the bug. With non-moving sbrk() in use, the crash usually happened when it tried to dump the (large) memory block sitting between the stack and the memory space reserved by the stub/crt0. The bug clearly is a Heisenbug: it may vanish, or appear again, just by power-cycling the machine. Soft reboot does *not* necessarily have the same effect. I.e: the bug may be related to the fragmented memory layout created by non-Unix sbrk. It happens as the coredumper tries to dumps a rather large memory block (several megabytes, typically) that isn't actually all used by the program (the coredump, if it succeeds, is around 500 to 700 KB, altogether). The details of the bug depend on the status of Windows' memory management, too, it seems. E.g., I failed to reproduce it at all, for several days. But for some reason I don't know, it reappeared after another turn-on of the machine, and once it has appeared, it happens somewhat reliably until shutdown. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.