delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/11/09/20:02:53

From: dcasale AT my-deja DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: Re: My program hangs under RHIDE's debugger
Date: Fri, 10 Nov 2000 00:53:36 GMT
Organization: Deja.com - Before you buy.
Lines: 54
Message-ID: <8ufgue$reg$1@nnrp1.deja.com>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1001109084112 DOT 16891F-100000 AT is> <8ueodf$5ep$1 AT nnrp1 DOT deja DOT com> <9743-Thu09Nov2000224218+0200-eliz AT is DOT elta DOT co DOT il>
NNTP-Posting-Host: 199.249.234.30
X-Article-Creation-Date: Fri Nov 10 00:53:36 2000 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
X-Http-Proxy: 1.1 x55.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 <9743-Thu09Nov2000224218+0200-eliz AT is DOT elta DOT co DOT il>,
  djgpp AT delorie DOT com wrote:
> > From: dcasale AT my-deja DOT com
> > Newsgroups: comp.os.msdos.djgpp
> > Date: Thu, 09 Nov 2000 17:55:00 GMT
> >
> > Like I said, this works outside the debugger.
>
> A program that runs outside a debugger but hangs under a debugger
> might have subtle bugs in it ;-)

Heh.  I found out what the "bug" was.  I have a JAZZ disk that I put my
build environment on.  I have my own workstation and a test machine,
both of which have JAZZ drives.  The interrupt call which scans for INT
13 extensions apparently doesn't like the JAZZ drive.  That's why it
hangs the second time around on this interrupt call.

I found this out by accident.  I tried running the compression program
from a floppy once, with the JAZZ disk ejected from the drive.  It's
running right now, and it'll probably crash at the end as usual.

Guess that means I need to copy my build environment to a separate
drive, eh?  ^^;;;

> > > 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.
>
> Something must be turning interrupts back on, or else the keyboard
> would stop working as well, and you will have a totally wedged
> system.

Yeah, I know.  He says that the internal code for INT 21h (which I also
use) checks to see if interrupts are turned off, and turns them back on
if necessary.  But, he says that if a certain error condition occurs
during an INT 13h call, the function jumps to a spot in the return code
which _misses_ the opcode to turn interrupts back on.

I don't know whether he's right or not, but since he has about ten
times more programming experience than I do, I tend to trust him on
these kinds of things.  :-)

[snip]

Damon Casale, damon AT WRONG DOT redshift DOT com
Talk about driving on the wrong side of the road (pun intended).


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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019