Message-ID: <353BC147.53FA@CGSTE.MQ> Date: Mon, 20 Apr 1998 16:42:31 -0500 From: HANRIGOU Philippe Reply-To: HANRIGOU AT cgste DOT mq Organization: CONSEIL GENERAL DE LA MARTINIQUE / DGA2 MIME-Version: 1.0 To: Eli Zaretskii CC: DJGPP Subject: Re: Problem with bash References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Eli Zaretskii wrote: > Okay, here's a few things I'd suggest to try: > > First, make sure it's really __dpmi_yield that gets you. Just comment > the call to it out, rebuild Bash and see if the problem goes away. > I've modified the __libc_termios_read_cooked_tty function like that: ("++" at line begining indicates added lines) static ssize_t __libc_termios_read_cooked_tty (int handle, void *buffer, size_t count) { unsigned char *wp; ssize_t n; wp = buffer; n = count; +++ trace("__libc_termios_read_cooked_tty: Begins, handle=%d count=%d", +++ handle, count +++ ); #if 0 /* clear cooked queue */ if (__libc_termios_exist_queue ()) __libc_termios_clear_queue (); #endif if (__libc_tty_p->t_lflag & ICANON) { /* get inputs (wait for NL or EOT) */ if (! __libc_termios_exist_queue ()) __libc_termios_fill_queue (); while (--n >= 0) { if (! __libc_termios_exist_queue ()) break; *wp++ = __libc_termios_get_queue (); } } else { /* block until getting inputs */ while (! __libc_termios_exist_queue ()) { +++ trace("__libc_termios_read_cooked_tty: Call __dpmi_yield"); __dpmi_yield (); +++ trace("__libc_termios_read_cooked_tty: Back from __dpmi_yield"); __libc_termios_fill_queue (); } while (--n >= 0) { *wp++ = __libc_termios_get_queue (); if (! __libc_termios_exist_queue ()) { __libc_termios_fill_queue (); if (! __libc_termios_exist_queue ()) break; } } } +++ trace("__libc_termios_read_cooked_tty: End, result is %d", +++ (ssize_t) (wp - (unsigned char *) buffer) +++ ); return (ssize_t) (wp - (unsigned char *) buffer); } Where "trace" is the function from "error.c". Below are the last lines of the trace file ("classic ls freezing session"). ---------------------- Last lines of trace file ----------------------- [stripped] TRACE: pid 6121: __libc_termios_read_cooked_tty: Call __dpmi_yield TRACE: pid 6121: __libc_termios_read_cooked_tty: Back from __dpmi_yield TRACE: pid 6121: __libc_termios_read_cooked_tty: Call __dpmi_yield TRACE: pid 6121: __libc_termios_read_cooked_tty: Back from __dpmi_yield TRACE: pid 6121: __libc_termios_read_cooked_tty: End, result is 1 TRACE: pid 6121: __libc_termios_read_cooked_tty: Begins, handle=0 count=1 TRACE: pid 6121: __libc_termios_read_cooked_tty: Call __dpmi_yield ------------------------- End of trace file --------------------------- So it really seems that bash never come back from last __dpmi_yield. If I comment this __dpmi_yield, bash still freezes (Didn't take time to figure out where, because I suspected others __dpmi_yield calls). But If I comment every __dpmi_yield call in tminit.c: EVERYTHING SEEMS OK (I ran a few djgpp commands without any trouble). > If __dpmi_yield *is* the problem, please look at the property sheets > of your DOS box, in the "Misc" tab, and tell what are your settings > there. I've got a french version of Windows 95. I've tried to translate these property sheets, but it's not sure that it correspond exactly to what's written in your "Misc tab": [Foreground] Allow screen saver = yes [Mouse] Quick edit = no Exclusive mode = no [Background] Suspend always = no [Stop] Alert if still active = yes [Idle Sensitivity] Sensitivity = medium [Others] Fast paste = no [Windows shortcuts] everything checked... > Next, try playing with the "Idle Sensitivity" setting and see > if that helps (mine is set to the lowest sensitivity). You will need > to restart the DOS box after every change. > I set Idle sensitivity to the lowest one: doesn't work (If I keep __dpmi_yield calls of course). > Also, see whether your %windir%/system.ini file has an > IdleVMWakeUpTime setting somewhere. If it does, please tell what does > it say. > It hasn't got any. > If nothing above seems to help or provide any clues, one other thing > to try would be to insert some code which will cause some screen > output inside the loop which calls __dpmi_yield. For example, you > could insert a call to __direct_outputs which prints a string " \b". > This will leave no visible trace on the screen. It might be that > writing to the screen repairs the bug without having the adverse > effects of not calling __dpmi_yield (programs which idle should not > eat up CPU time). > Still interesting? I haven't slept too much this night and I feel a bit lazy. Tell me whether it still helps... > I don't think you need to plunge into DPMI specifics for this > problem. The name __dpmi_yield suggests that this is a DPMI function, > but it really isn't. Ok. You said that __dpmi_yield just yields the rest of the current time slice so other programs get CPU control. So, what is the problem if I use a bash with all __dpmi_yield calls commented? I guess, I'll have a monotask behaviour of bash as opposed to others applications, but will I have a good multitasking emulation for commands launched from bash (background jobs facilities, etc.)? Thanks you very much for all your help, Regards, Philippe. _______________________________________________________________________ Philippe HANRIGOU Conseil Général de la Martinique Ingénieur informatique D.D.S.T. - service I.T.S. Immeuble Concorde, route de la Folie Tél: (0596) 59-84-63 97200 Fort de France E-mail: HANRIGOU AT cgste DOT mq FRANCE _______________________________________________________________________