Date:	Mon, 31 Aug 1998 11:47:48 +0200 (MET DST)
From:	Olivier Perron <perron AT art DOT alcatel DOT fr>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	Nate Eldredge <nate AT cartsys DOT com>, djgpp AT delorie DOT com
Subject:	Re: Computer freeze when using latest version of vim and bash as inferior shell
In-Reply-To:	<Pine.SUN.3.91.980831122832.22974c-100000@is>
Message-Id:	<Pine.GSO.3.96.980831114248.2658C-100000@rtbsci145s>
Mime-Version:	1.0

On Mon, 31 Aug 1998, Eli Zaretskii wrote:

> 
> On Mon, 31 Aug 1998, Olivier Perron wrote:
> 
> > OK, I've just rebuild bash using your patched libc: it also have the same
> > problem.
> > (If I type a simple 'ls' command, nothing happens and I lost control in
> > the dos box.)
> 
> Please run Bash under a debugger and tell where does it hang.  I use the 
> patched libc for more than a year and didn't have any problems.
> 

I've done the following:

gdb bash
run
ls
(then I lost control, so I hit Ctrl-C, and gdb regain control)
info stack

(gdb) info stack
#0  0x43bfe in __dpmi_int ()
#1  0x516b9 in _truename ()
#2  0x48a2b in _ioctl_get_first_cluster ()
#3  0x492f1 in stat ()
#4  0x11942 in file_status (name=0xc7b80 "X://ls") at execute_cmd.c:4199
#5  0x11e29 in find_user_command_in_path (name=0xaa388 "ls",
    path_list=0xa8300 ".:/DJGPP/BIN://Y/PUBLIC://X/:/USR/BIN://Z/:/GS:/EMACS-19.
34/BIN:/NC:/NU:/:/AP/CCMAIL/CCMAIL:/WINDOWS:/WINDOWS:/WINDOWS/COMMAND:/LCC/BIN",
 flags=4) at execute_cmd.c:4588
#6  0x11a76 in find_user_command_internal (name=0xaa388 "ls", flags=4)
    at execute_cmd.c:4339
#7  0x11a05 in find_user_command (name=0xaa388 "ls") at execute_cmd.c:4307
#8  0x10198 in execute_disk_command (words=0xc7bc0, redirects=0x0,
    command_line=0xbe000 "ls -F --color", pipe_in=-1, pipe_out=-1, async=0,
    fds_to_close=0xc7b10, nofork=0) at execute_cmd.c:2631
#9  0xf99b in execute_simple_command (simple_command=0xc62c0, pipe_in=-1,
    pipe_out=-1, async=0, fds_to_close=0xc7b10) at execute_cmd.c:2081
#10 0xe663 in execute_command_internal (command=0xc62e0, asynchronous=0,
    pipe_in=-1, pipe_out=-1, fds_to_close=0xc7b10) at execute_cmd.c:834
#11 0xdd2d in execute_command (command=0xc62e0) at execute_cmd.c:297
#12 0x461e in reader_loop () at shell.c:1237
#13 0x3f3e in main (argc=1, argv=0xa7070, env=0xa8100) at shell.c:872
#14 0x4153a in __crt1_startup ()


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.

Did something change in truename in the pactched libc ?

Olivier.

- Raw text -