Date: Mon, 31 Aug 1998 15:54:15 +0200 (MET DST) From: Olivier Perron To: Eli Zaretskii Cc: djgpp AT delorie DOT com Subject: Re: Computer freeze when using latest version of vim and bash as inferior shell In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 31 Aug 1998, Eli Zaretskii wrote: > > On Mon, 31 Aug 1998, Olivier Perron wrote: > > > #0 0x43bfe in __dpmi_int () > > #1 0x516b9 in _truename () > > #2 0x48a2b in _ioctl_get_first_cluster () > > #3 0x492f1 in stat () > > I don't understand this. First, _ioctl_get_first_cluster doesn't call > _truename. And second, why does it hang? Can you look around and tell > me exactly which call to __dpmi_int has hanged? > Yes, it is not understandable. It is the dpmi_int call at line 120 of patched truename.c (patch PTF0018) which hanged. > I believe Nate has a source of the version of stat that is linked into > this library, if you need to look into the sources. Maybe the easiest > way to debug this would be to compile stat.c with -DTEST and use the > simple test program that this produces to investigate. If I understand > correctly, you should see the test program hang as well. > I did rebuild the patched stat.c with patches PTF0013 abd PTF0248. If I run the test program, I always have the following answer: DOS 7.10 (MS-DOS) > What version of Windows do you run, btw? All versions of DOS and > Windows 9X I could try don't support that IOCTL call, so maybe yours is > the first one that does, in which case I'd be very interested to know > what goes wrong there. Windows95 OSR2 4.00.950 B also known as 4.00.1111 > > Also, is X: some kind of special drive? If so, what kind is it? (I'm > asking that because I understand that several directories were > successfully checked before X:/, and didn't cause Bash to hang, so it > might be something special to that X: drive.) > > > #4 0x11942 in file_status (name=0xc7b80 "X://ls") at execute_cmd.c:4199 > ^^^^^^ > Why is the ls pathname formatted so strangely? (It shouldn't really > matter, but I'm puzzled anyway.) > X is a net drive and is declared in the PATH as X:\ by the system administartor. I think that's why bash look for X://ls. > > I suppose the problem is in truename, not in dpmi_int. I guess dpmi_int is > > in the stack because I had to hit Ctrl-C to regain control. > > I don't think so. First, it is not clear to me whether _truenam or > _ioctl_get_first_cluster hangs. And second, it probably hangs inside > __dpmi_int. But those are only guesses; please see if you can see what > in fact happens. > As far as I have seen, it is _truename which calls __dpmi_int which hangs. But I've not seen any call to _ioctl_get_first_cluster between truename and dpmi_int. > > Did something change in truename in the pactched libc ? > > I don't think so. Nate, could you please look? > There's a patch PTF0018 which fixes bug in LFN environment. And, you are the author of this patch.