Date:	Sun, 1 Jun 1997 16:14:40 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Fred Smith <fredex AT fcshome DOT stoneham DOT ma DOT us>
cc:	djgpp AT delorie DOT com
Subject:	Re: program hangs in __dpmi_int
In-Reply-To:	<EAz2Mq.nt3@fcshome.stoneham.ma.us>
Message-ID:	<Pine.SUN.3.91.970601161409.24182G-100000@is>
MIME-Version:	1.0

On Fri, 30 May 1997, Fred Smith wrote:

> #0 xxxxx in __dpmi_int ()
> #1 xxxxx in __lseek()
> #2 xxxxx in get ()
> #3 ...
> 
> The function get() is one of our file management routines, calls lseek 
> then read. What I don't know is what is __dpmi_int(), what it does, why
> it is called here, and what I could be doing elsewhere in the program
> that would cause it to hang.

`__dpmi_int' is the low-level interface to DOS and BIOS functions.
Since DJGPP programs run in protected mode, they need to call
real-mode DOS and BIOS functions through a special DPMI service.
`__dpmi_int' calls this service.  (Btw, this is explained in the DJGPP
FAQ list, section 13.5.)  Since `lseek' calls a DOS function, it does
so through `__dpmi_int'.

> At this point I don't know what parameters
> are being passed to lseek(), but will try finding out tomorrow.

That is what you probably should do.  `__dpmi_int' is so heavily used
by every DJGPP program that it is highly improbable that you have
found a bug there.  It is much more probable that `get' in your
program somehow enters an endless loop whereby it calls `lseek' time
and again, until you kill it.  Perhaps some snafu with text/binary
file I/O?  Suppose the program assumes that it needs to read a certain
number of bytes from a file, and if `read' returns less, waits to get
more on the assumption that some other program still writes to it?
But I'm guessing; looking at `get' should unlock the problem.

- Raw text -