Date: Mon, 2 Apr 2001 09:52:34 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Nimrod A. Abing" <n_abing AT ns DOT roxas-online DOT net DOT ph>
cc: djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: That crash message from the core dumper.
In-Reply-To: <3.0.1.32.20010402073555.006c5e2c@wingate>
Message-ID: <Pine.SUN.3.91.1010402095111.26715D-100000@is>
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 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]
> 
> Call frame traceback EIPs:
>   0x000090b1 ___dj_movedata+33
>   0x000087dc ___dosmemput+44
>   0x0000572b __write+123
>   0x00002d85 __crt0_init_mcount+6089
>   0x000036e5 ___djgpp_traceback_exit+177
>   0x00003786 _raise+118
>   0x00006094 _abort+36
>   0x00003e6b _f1+11
>   0x00003e7f _f2+11
>   0x00003e8f _f3+11
>   0x00003e9f _main+11
>   0x000052d8 ___crt1_startup+204

Fascinating.

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?

But the plot thickens even more.  This line from the crash message:

> Page fault at eip=000090b1, error=0004

says that the faulting page was being _read_ from.  However, the ES
register is used by ___dj_movedata as a selector for the _destination_
address, not for the source.  So I don't see how ES can be the problem
here.  Nimrod, could you please disassemble __dj_movedata and see what
instruction is at ___dj_movedata+33?  I suspect that it is this:

	rep
	movsl

which is disassembled by GDB like this:

        repz movsl %ds:(%esi),%es:(%edi)

This would mean that the DS:ESI pair should be the only culprit for a
Page Fault with error code 4.  But I don't see anything wrong with
DS:ESI in the crash message!

There's also something weird in the value of EDI.  Since this is
_write calling movedata to move data to the transfer buffer, and
_write moves data in chunks of transfer buffer size, i.e. 16KB, EDI
shouldn't be more than 16K.  So how come we see a much larger value in
the crash message?

Nimrod, do all the crashes which happen when the AV software is
enabled always point to the same instruction inside the program, and
show the same values of all the registers in the crash message?

> Anyway, I've tracked it down to my AV software as I've mentioned in a
> previous post. I turned off real-time scanning and everything went on
> smoothly.

I'm at a loss how could an antivirus cause such crashes.  Can someone
explain?