Mail Archives: djgpp-workers/2001/01/21/11:20:34
> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Sun, 21 Jan 2001 14:53:04 +0100
>
> > First, make sure the problem persists with stock v2.03 library. If it
> I'm using the stock 2.03 library.
Then you might consider replacing itimer.c with what's currently in
the CVS: there was a small bug in the released version. I don't know
if it affects this specific problem, but you never know...
> > does, I'd first suspect that Smalltalk's `relinquish' isn't as innocent
> > as your description suggests; perhaps it does something which in the DJGPP
> > case disables or interferes with the signal handling machinery.
> Hmmm. relinquish itself is pretty innocent:
>
> void
> relinquish(usecs)
> int usecs;
> {
> /* Please feel free to make this more accurate for your operating system
> * and send me the changes.
> */
> #if defined(WIN32)
> Sleep((usecs + 999) / 1000);
> #else
> #ifdef HAVE_SELECT
> struct timeval time;
> time.tv_sec = usecs / 1000000;
> time.tv_usec = usecs % 1000000;
>
> select(0, NULL, NULL, NULL, &time);
> #endif
> #endif
> }
Please show the code which sets up the timer and the signal handler.
And what is the value of the argument to `relinquish' in this
particular test?
> Exiting due to signal SIGALRM
> Exception 78 at eip=0004b630
This sounds like some problem with how the signal handler was set, or
what it did. The above would be the expected result if the signal
handler for SIGALRM was reset to SIG_DFLT. Can you add some debugging
print-out to the signal handler that will show whether it is called or
not?
> eax=00000000 ebx=0000002f ecx=00000000 edx=0000000d esi=00000000 edi=000f7728
> ebp=000f76fc esp=000f76f0 program=H:\TMP\SOURCE\SMALLT~1.5\GST.EXE
> cs: sel=00a7 base=84026000 limit=ffff8fff
> ds: sel=00af base=84026000 limit=ffff8fff
> es: sel=00b7 base=84026000 limit=ffff8fff
> fs: sel=0087 base=0000a740 limit=0000ffff
> gs: sel=00bf base=00000000 limit=0010ffff
> ss: sel=00af base=84026000 limit=ffff8fff
> App stack: [000f8450..00078450] Exceptn stack: [00078380..00076440]
>
> Call frame traceback EIPs:
> 0x0004b630 ___dpmi_simulate_real_mode_interrupt+48
> 0x0004210c ___dpmi_yield+44
> 0x0003d2e9 _sleep+25 (or _select, if that was used)
> 0x000187db _relinquish+43
> 0x00010cf5 _emptyContextPool+8205
I don't see anything remarkable here.
> > As another data point, does a simple test program which sets up a timer
> > and then calls `select' to wait forever succeeds to DTRT?
> I tried a simple program that set a 3-second alarm using setitimer, then
> slept for 10 seconds. While it did take slightly longer than 3 seconds,
> it did fire properly; no SIGALRM exit.
As expected. The next suspect for the cause of the problem is
probably the code which sets up the timer or in the signal handler.
Oh, btw: this run on Windows, right? On Windows, you need to make
sure the DOS box where the program is running never goes int
background, because Windows almost stops delivering timer tick
interrupts to background programs (they get something like 10% of
ticks).
> > Also, make sure you do NOT run this under a debugger. The DJGPP debug
> > support doesn't work reliably when timers fire, this is a known bug for
> > which there's no solution or work-around yet. If you did run this under
> > a debugger, chances are your observations have very little to do with the
> > actual problems.
> OK. But since we're dealing with an interpreted language, I figured trying
> to debug something would prove difficult even without the timer stuff.
Why? I routinely run Emacs (another interpreter) under GDB with no
visible problems. I even debug GDB itself with GDB, although it has a
command-line interpreter built into it.
- Raw text -