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 <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp workers list <djgpp-workers AT delorie DOT com>
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:	<Pine.LNX.4.10.10104231447330.5316-100000@acp3bf>
MIME-Version:	1.0
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

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.

- Raw text -