From: dcasale AT my-deja DOT com Newsgroups: comp.os.msdos.djgpp Subject: Re: My program hangs under RHIDE's debugger Date: Thu, 09 Nov 2000 17:55:00 GMT Organization: Deja.com - Before you buy. Lines: 89 Message-ID: <8ueodf$5ep$1@nnrp1.deja.com> References: NNTP-Posting-Host: 199.249.234.30 X-Article-Creation-Date: Thu Nov 09 17:55:00 2000 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) X-Http-Proxy: 1.1 x65.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 In article , djgpp AT delorie DOT com wrote: > > On Thu, 9 Nov 2000 dcasale AT my-deja DOT com wrote: > > > Okay, I'm back with a slightly different problem. > > Welcome back ;-) Heh. I don't know whether to cheer or cry. ;-p :-) > > 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. > > Did you try this on plain DOS or on Windows? If the former, did you > use CWSDPMI as your DPMI host? YAMD will not work except with CWSDPMI > or DPMI 1.0 host. Yes, I ran it in plain DOS. (It does direct disk access; it won't even run in WinBlows.) Yes, I used CWSDPMI. > > // 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); > > What is sizeof(*pINT13DP)? How many bytes did you mean to copy to the > transfer buffer? // Used to retrieve the file system type (normal or extended FAT) typedef struct _INT13DriveParams { WORD BufferSize; WORD InfoFlags; DWORD PhysicalCylinders; DWORD PhysicalHeads; DWORD PhysicalSectors; QWORD TotalSectors; WORD BytesPerSector; } INT13DriveParams; 26 bytes (1A hex) total. Like I said, this works outside the debugger. > > asm volatile ("pushf" : : ); > > __dpmi_int (0x13, ®s); /* call BIOS */ <--- hangs here > > asm volatile ("popf" : : ); > > Why did you insert PUSHF and POPF? They are not needed for > __dpmi_int calls; I suggest to remove them. Because another programmer who was working on this code before me found that with _some_ __dpmi_int int 13h calls, interrupts were mysteriously turned off after the call returned. That _may_ be the reason my system clock is slowing down. I've just been adding pushf and popf around the interrupt calls to forestall that problem. > > I'm guessing that RHIDE's debugger might be using the transfer > > buffer itself, thus overwriting what I just put there. > > No, this guess is wrong: the DJGPP debug support arranges for the > debuggee to have a separate transfer buffer, to avoid problems with > stepping through system calls. This is done in the function that > loads the debugged program and prepares it for execution, effectively > replacing the stub loader; see the source of the function v2loadimage > in djlsr203.zip. Hmm. Okay, then. > > Any ideas? > > The Interrupt List says something about specific BIOSes which fail to > handle this function correctly if the flag word at DS:[SI+2] is not > 0000h on entry. Are you sure you zero that word? You mean InfoFlags in the structure above? No, I don't zero that. I'll check to see if that's the problem. Thanks. Damon Casale, damon AT WRONG DOT redshift DOT com (remove the obvious) PEEK and POKE is a game played by young programmers. Sent via Deja.com http://www.deja.com/ Before you buy.