Date: Sun, 21 Jan 2001 18:17:17 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Tim Van Holder" Message-Id: <7458-Sun21Jan2001181716+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 CC: djgpp-workers AT delorie DOT com In-reply-to: Subject: Re: Interaction between __dpmi_yield and signals? References: Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Tim Van Holder" > 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.