Mail Archives: djgpp-workers/2000/05/28/21:09:30
> Another thing to try would be to run programs from REDIR. The version
> shipped with v2.03 toggles all exceptions before running the child
> program, so it might reveal some additional information. For example,
> try running a compilation from Make, but through REDIR instead of
> directly, possibly several nested REDIR's.
Interesting test results:
The nesting 3 level deep sequence:
make / redir /echo2
shows frequent failures
The nesting 3 level deep sequence:
redir /make /echo2
seems to be stable
The nesting 3 level deep sequence:
redir / gcc -c -O2 *.c
seems to be stable
The nesting 3 level deep sequence:
go32-v2 \djgpp\gcc.exe -O2 -c @c.inp
seems to be stable (it won't take *.c for some reason, and this is 3 level
nesting - does go32-v2 unhook interrupts?)
So, maybe the unhooking helps if it is done at the top level?
I did see one isolated failure running gcc standalone - immediately after
booting into NT (the .exe image created was corrupt also) but that was an
isolated incident that I can't reproduce).
> > FAULT ->77e89b01 e9d2030300 jmp SetThreadContext+0x46 (77eb9ed8)
>
> It seems to crash when it jmp's to one of its own routines. How can that
> happen?
Well it is a microsoft product ...
It could be due to a code segment limit violation, or a page fault.
The address in () looks semi-reasonable but is larger than anything else
in the tiny segment of code we see. Who knows.
- Raw text -