Mail Archives: djgpp-workers/2001/04/24/02:55:52
Hello.
At 03:03 PM 04/23/2001 +0200, you wrote:
>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.
<*grrr*> This thing *still* happens even with InnoculateIT uninstalled. So
IPE *is* out of this equation. It must be something in Windoze. The
significance of CWSDPMI in this case is that this crash *never* happens,
that narrows the problem to Windoze.
>But some further testing this weekend revealed even more strange
>behaviour.
Hmmm. I'll go try this out myself to see if I get the same results...
>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
Progress 11, yup! Same spot where the thing crashes. I'll have to look into
the way the memory segment offsets are calculated by the core dumper yet
again.
>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.
I definitely have to look into those calculations...
>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.
nimrod_a_abing
--------------
+========================================+
| Home page: www.geocities.com/n_abing |
+========================================+
"Tinimbang ka ngunit kulang."
If you understand that phrase, i-email mo'ko. ;-)
- Raw text -