From: dcasale AT my-deja DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: My program hangs under RHIDE's debugger
Date: Thu, 09 Nov 2000 01:35:47 GMT
Organization: Deja.com - Before you buy.
Lines: 45
Message-ID: <8ucv1j$nff$1@nnrp1.deja.com>
NNTP-Posting-Host: 199.249.234.30
X-Article-Creation-Date: Thu Nov 09 01:35:47 2000 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
X-Http-Proxy: 1.1 x56.deja.com:80 (Squid/1.1.22) for client 199.249.234.30
X-MyDeja-Info: XMYDJUIDdcasale
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Okay, I'm back with a slightly different problem.  Ignoring the
mysterious slowdown problem in my compression program for the moment,
I'm trying to track down the cause of a crash which happens on one
particular delete.  I don't think it's this particular delete that's
causing the problem; I think I might have corrupted memory earlier in
the program execution.

I tried experimenting around with Nate Eldredge's YAMD (Yet Another
Malloc Debugger), but my program hung almost right at the beginning,
and didn't even get close to where the original crash occurs.  Okay, I
thought, I'll try RHIDE's debugger and see if that gets me anywhere.
Well, no joy.  The program hangs at the same point (my guess -- the
screen output is my clue).  So I step through the code until the hang
occurs.  It's happening right at this point in my code:

...
    // Check to see if the INT 13 HD extensions are present...
    if( ( (regs.x.flags & 1) == 0 ) && ( regs.x.bx == 0xAA55 ) )
    {
        regs.h.ah = 0x48;
        regs.h.dl = PhysicalDriveNumber;
        regs.x.si = __tb & 0x0f ;
        regs.x.es = regs.x.ds = __tb >> 4 ;
        pINT13DP->BufferSize = 0x1A;
        dosmemput(pINT13DP,sizeof(*pINT13DP),__tb);
	asm volatile ("pushf" : : );
        __dpmi_int (0x13, &regs);  /* call BIOS  */  <--- hangs here
	asm volatile ("popf" : : );
        dosmemget (__tb, sizeof(*pINT13DP), pINT13DP);

        if( (regs.x.flags & 1) == 0 )
...

I'm guessing that RHIDE's debugger might be using the transfer buffer
itself, thus overwriting what I just put there.

Any ideas?

Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious)
Yeah, I might be able to get it to go a little faster.  But first I
have to get it to stop crashing.


Sent via Deja.com http://www.deja.com/
Before you buy.