Mail Archives: djgpp-workers/2001/04/04/07:52:08
Eli said:
> On Mon, 2 Apr 2001, Nimrod A. Abing wrote:
> > writing contents of address 00020000
> > block size 2228224
> > Exiting due to signal SIGSEGV
> > An error occured while writing core file. (signal: 14, progress number: 11)
> > Page fault at eip=000090b1, error=0004
> > eax=00000200 ebx=00004000 ecx=00001000 edx=00013d00 esi=00030000 edi=00013d00
> > ebp=002b6d2c esp=002b6d1c program=C:\PROJECTS\PMDB\COREDUMP\ABRT.EXE
> > cs: sel=021f base=830fd000 limit=002b6fff
> > ds: sel=0247 base=830fd000 limit=002b6fff
> > es: sel=0257 base=00000000 limit=0010ffff
> > fs: sel=0257 base=00000000 limit=0010ffff
> > gs: sel=0257 base=00000000 limit=0010ffff
> > ss: sel=0247 base=830fd000 limit=002b6fff
> > App stack: [002b7000..00237000] Exceptn stack: [0000ff30..0000dff0]
> There are several things I don't understand here. First, ES, FS, and
> GS got all set to the _dos_ds segment selector. This is normal for GS
> (the library does that), but not for FS and _certainly_ not for ES.
> Does the core dumping code use _far* functions, or manipulates FS in
> any other way? And who loaded the _dos_ds selector into ES? Can you
> see any code which fiddles with ES in the core dumper?
I have not much to say about the dump, but I have some questions
prompted by it.
Shouldn't the limit on _dos_ds selector be 0x10ffef (or possibly
0x10fff0, I'm not sure if the limit includes the last address or not)
instead of 0x0010ffff?
The signal was SIGSEGV. Isn't that number 11? Still the next line from
the core dumper says "signal: 14"? Huh?!
Right,
MartinS
- Raw text -