Mail Archives: djgpp/1998/08/31/09:56:15
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.
- Raw text -