gnu/77818: GDB locks in wait4() when running applications
Seán C. Farley
sean-freebsd at farley.org
Mon Apr 25 12:20:16 PDT 2005
The following reply was made to PR gnu/77818; it has been noted by GNATS.
From: =?ISO-8859-1?Q?Se=E1n_C=2E_Farley?= <sean-freebsd at farley.org>
To: David Xu <davidxu at freebsd.org>
Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-bugs at freebsd.org
Subject: Re: gnu/77818: GDB locks in wait4() when running applications
Date: Mon, 25 Apr 2005 14:17:28 -0500 (CDT)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-583420044-1114456648=:25522
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Tue, 19 Apr 2005, David Xu wrote:
> I have commited a fix to -CURRENT, don't know if it will fix the
> problem you have seen, but it is worth to try.
>
> David Xu
>
> Se=E1n C. Farley wrote:
>
>> I finally compiled Zsh with debugging and got the following trace. I
>> ran it by the following line:
>> LD_LIBRARY_PATH=3D/tmp/libc SHELL=3D/bin/sh gdb /usr/local/bin/zsh
>>=20
>> Program received signal SIGINT, Interrupt.
>> 0x281a9efb in sigsuspend () from /lib/libc.so.5
>> (gdb) where
>> #0 0x281a9cfb in sigsuspend () at sigsuspend.S:2
>> #1 0x280e07dc in signal_suspend (sig=3D20, sig2=3D2) at signals.c:367
>> #2 0x280b92e8 in waitforpid (pid=3D11195) at jobs.c:1120
>> #3 0x280a3dda in getoutput (cmd=3D0x8060e5c "uname -s", qt=3D1) at exec=
=2Ec:2869
>> #4 0x280e2a0c in stringsubst (list=3D0xbfbfe7c0, node=3D0xbfbfe7d0, ssu=
b=3D4,
>> asssub=3D0) at subst.c:189
>> #5 0x280e2378 in prefork (list=3D0xbfbfe7c0, flags=3D6) at subst.c:74
>> #6 0x280a0886 in addvars (state=3D0xbfbfe880, pc=3D0xbfbfe7c0, export=
=3D0)
>> at exec.c:1614
>> #7 0x2809ec5d in execsimple (state=3D0x1) at exec.c:802
>> #8 0x2809edb7 in execlist (state=3D0xbfbfe880, dont_change_job=3D0, exi=
ting=3D0)
>> at exec.c:855
>> #9 0x2809eb9a in execode (p=3D0x80608e0, dont_change_job=3D0, exiting=
=3D0)
>> at exec.c:775
>> #10 0x280b3a8a in loop (toplevel=3D0, justonce=3D0) at init.c:165
>> #11 0x280b58b8 in source (s=3D0xbfbfe950 "/root/.zshenv") at init.c:1043
>> #12 0x280b5b1c in sourcehome (s=3D0x280f458d ".zshenv") at init.c:1088
>> #13 0x280b54e7 in run_init_scripts () at init.c:937
>> #14 0x280b63da in zsh_main (argc=3D1, argv=3D0xbfbfeac0) at init.c:1262
>> #15 0x08048583 in main (argc=3D1, argv=3D0xbfbfeac0) at ./main.c:93
>>=20
>> I hope this can help find the problem.
Would you happen to have a patch to -STABLE for the fix? I looked at
some of the code you committed recently and was unsure of what fix(es)
needed to be made to test it. A few of the changes did not look like
they matched easily to -STABLE.
Thank you.
Se=E1n
--=20
sean-freebsd at farley.org
--0-583420044-1114456648=:25522--
More information about the freebsd-bugs
mailing list