Latest stable (r287104) bash leaves zombies on exit
I updated to stable yesterday, plus updated all my porst to the latest pecompiled packages, but I am now seeing odd problems with bash on exit. Sometimes it quits, but leaves a zombie process... e.g PID TT STATTIME COMMAND 44308 v0 IW 0:00.00 -bash (bash) 44312 v0 IW+ 0:00.00 /bin/sh /usr/local/bin/startx -listen_tcp 44325 v0 IW+ 0:00.00 xinit xterm -listen_tcp -- /usr/local/bin/X :0 -auth /ho 44328 v0 IW 0:00.00 /usr/local/bin/wmaker 44340 v0 S0:03.35 /usr/local/bin/wmaker --for-real 49101 0- Z+ 0:02.73 49314 1- Z+ 0:00.17 56068 2 Ss 0:00.01 bash 56498 2 R+ 0:00.00 ps 56074 3 Is 0:00.01 bash 56076 3 S+ 0:00.00 mail freebsd-stable@freebsd.org 56308 4 Is+ 0:00.01 bash Thats the current 'ps' on this machine. The bash processes are running inside an xterm, so am not sure if the issue is with bash or the terminal. Kind of puzzled! -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
As noted yestterday, this issue only happens in an xterm as far as I can make out. When back becomes a zombie then the xtrem enters state urdlck according to ps. I tried removing and reinstalling all ports today, in the hopes that might fix it, but the problem is still there. Is anyone else seeing this, and does anyone have any suggestions as to how tof ix it ? The xtrems still respond in as much as they can be dragged around, miaturised, resized etc, but they never quit, and the content inside them does not refresh. I am runnign WindowMaker as a WM if that might be part of the problem ? Currently I have to reboot the machine periodicly once I have accumulated enough zombies to be annoying. Its not really a long term solution though. -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
Am Mittwoch, 26. August 2015 schrieb Pete French: > As noted yestterday, this issue only happens in an xterm > as far as I can make out. When back becomes a zombie > then the xtrem enters state urdlck according to ps. I > tried removing and reinstalling all ports today, in the hopes that > might fix it, but the problem is still there. > > Is anyone else seeing this, and does anyone have any suggestions > as to how tof ix it ? The xtrems still respond in as much as they can be > dragged around, miaturised, resized etc, but they never quit, and the > content inside them does not refresh. I am runnign WindowMaker as a WM if > that might be part of the problem ? > > Currently I have to reboot the machine periodicly once I have accumulated > enough zombies to be annoying. Its not really a long term solution though. > > -pete. Hi Pete! I cannot reproduce the error, but I'm using fvwm. Can you give a step-bystep instruction to reproduce the error? nik -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
> Hi Pete! > > I cannot reproduce the error, but I'm using fvwm. Can you give a step-bystep > instruction to reproduce the error? > > nik Hello Nik, thanks for looking at this for me - I havent yet found a reliable way to reproduce it unfortunately. It seems to happen on wiindows where I have run 'vi' or where I have logged in to another machine on ssh, but then thats mainly what I do in my wondows, so its hardly surprising ;-( Is there anything I can do to investiagett eh status of the stuck processes. I have managed to get 4 in the last hour here. -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
Pete French wrote: I updated to stable yesterday, plus updated all my porst to the latest pecompiled packages, but I am now seeing odd problems with bash on exit. Sometimes it quits, but leaves a zombie process... e.g PID TT STATTIME COMMAND 44308 v0 IW 0:00.00 -bash (bash) 44312 v0 IW+ 0:00.00 /bin/sh /usr/local/bin/startx -listen_tcp 44325 v0 IW+ 0:00.00 xinit xterm -listen_tcp -- /usr/local/bin/X :0 -auth /ho 44328 v0 IW 0:00.00 /usr/local/bin/wmaker 44340 v0 S0:03.35 /usr/local/bin/wmaker --for-real 49101 0- Z+ 0:02.73 49314 1- Z+ 0:00.17 56068 2 Ss 0:00.01 bash 56498 2 R+ 0:00.00 ps 56074 3 Is 0:00.01 bash 56076 3 S+ 0:00.00 mail freebsd-stable@freebsd.org 56308 4 Is+ 0:00.01 bash Thats the current 'ps' on this machine. The bash processes are running inside an xterm, so am not sure if the issue is with bash or the terminal. Kind of puzzled! I can reproduce this easily, although not every time. Running 10.2 under KDE, with bash as a default shell: start xterm from a KDE 'konsole', then move to within the xterm and try closing it (^D or exit). More often than not the xterm will block and stay open, the bash process within goes . A normal kill of xterm has no effect, although a kill -9 to the xterm blows away the xterm and the init process then clears the bash zombie leftover. Seems like running a simple command like 'date' in xterm before trying to close it does increase the likelihood that xterm will block on exit. Currently I have to reboot the machine periodicly once I have accumulated enough zombies to be annoying. Its not really a long term solution though. There is no need to reboot, just kill -9 the hanging xterm processes and the init will clear the zombies. Mark ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
> I can reproduce this easily, although not every time. Ah, thats good to hear, as it means I am not going completely mad, thanks! :) > Running 10.2 under KDE, with bash as a default shell: > start xterm from a KDE 'konsole', then move to within the xterm > and try closing it (^D or exit). More often than not the xterm > will block and stay open, the bash process within goes . As you can reproduce this, is it possible for you to find out if the issue is with bash or xterm ? i.e. if you change the shell to /bin/sh then does it still do it ? That would help track it down... > There is no need to reboot, just kill -9 the hanging xterm processes > and the init will clear the zombies. Thats saved me a lot of time ;) I had this idea that zombies will only go away on a reboot. -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Thu, Aug 27, 2015 at 02:04:05PM +0200, Mark Martinec wrote: > Pete French wrote: > > > I updated to stable yesterday, plus updated all my porst to > > the latest pecompiled packages, but I am now seeing odd problems > > with bash on exit. Sometimes it quits, but leaves a zombie > > process... e.g > > > > PID TT STATTIME COMMAND > > 44308 v0 IW 0:00.00 -bash (bash) > > 44312 v0 IW+ 0:00.00 /bin/sh /usr/local/bin/startx -listen_tcp > > 44325 v0 IW+ 0:00.00 xinit xterm -listen_tcp -- /usr/local/bin/X :0 > > -auth /ho > > 44328 v0 IW 0:00.00 /usr/local/bin/wmaker > > 44340 v0 S0:03.35 /usr/local/bin/wmaker --for-real > > 49101 0- Z+ 0:02.73 > > 49314 1- Z+ 0:00.17 > > 56068 2 Ss 0:00.01 bash > > 56498 2 R+ 0:00.00 ps > > 56074 3 Is 0:00.01 bash > > 56076 3 S+ 0:00.00 mail freebsd-stable@freebsd.org > > 56308 4 Is+ 0:00.01 bash > > > > Thats the current 'ps' on this machine. The bash processes are running > > inside an xterm, so am not sure if the issue is with bash or the > > terminal. Kind of puzzled! > > I can reproduce this easily, although not every time. > > Running 10.2 under KDE, with bash as a default shell: > start xterm from a KDE 'konsole', then move to within the xterm > and try closing it (^D or exit). More often than not the xterm > will block and stay open, the bash process within goes . > > A normal kill of xterm has no effect, although a kill -9 to the > xterm blows away the xterm and the init process then clears > the bash zombie leftover. Seems like running a simple command > like 'date' in xterm before trying to close it does increase > the likelihood that xterm will block on exit. > > > > Currently I have to reboot the machine periodicly once I have > > accumulated > > enough zombies to be annoying. Its not really a long term solution > > though. > > There is no need to reboot, just kill -9 the hanging xterm processes > and the init will clear the zombies. Try to obtain the backtrace from the hung xterm. Ideally, you would rebuild xterm and the system libraries (rtld+libc+libthr) with debug symbols and get the backtraces after that. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
> Try to obtain the backtrace from the hung xterm. Ideally, you would > rebuild xterm and the system libraries (rtld+libc+libthr) with debug > symbols and get the backtraces after that. I can try this tomorrow - what do I need to set in src.conf to add debug symbols in when I do a buidlworld (thats what I would end up doing) ? never played with this bit - am hoping its as simple as 'DEBUG=yes' for both porst and world though! cheers, -pete. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Thu, Aug 27, 2015 at 06:06:26PM +0100, Pete French wrote: > > Try to obtain the backtrace from the hung xterm. Ideally, you would > > rebuild xterm and the system libraries (rtld+libc+libthr) with debug > > symbols and get the backtraces after that. > > I can try this tomorrow - what do I need to set in src.conf to add > debug symbols in when I do a buidlworld (thats what I would end > up doing) ? never played with this bit - am hoping > its as simple as 'DEBUG=yes' for both porst and world though! For ports, it is probably WITH_DEBUG=yes, but check it. For src, do cd /usr/src (cd lib/libc && make DEBUG_FLAGS=-g all install) (cd lib/libthr && make DEBUG_FLAGS=-g all install) (cd libexec/rtld-elf && make DEBUG_FLAGS=-g all install) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
The xterm program has a SIGCHLD signal handler that calls wait().
If the handler is invoked while xterm is exiting, a deadlock occurs in rtld.
Cheers
Michiel
#0 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
#1 0x00080305a2b0 in __thr_rwlock_rdlock (rwlock=0x803272980,
flags=, tsp=)
at /usr/src/lib/libthr/thread/thr_umtx.c:277
#2 0x00080306179c in _thr_rtld_rlock_acquire (lock=0x803272980)
at thr_umtx.h:196
#3 0x0008006a72c2 in rlock_acquire (lock=0x8008ba860,
lockstate=0x7fffd5b8) at /usr/src/libexec/rtld-elf/rtld_lock.c:201
#4 0x0008006a0c8d in _rtld_bind (obj=0x8006bc000, reloff=6840)
at /usr/src/libexec/rtld-elf/rtld.c:701
#5 0x00080069e46d in _rtld_bind_start ()
at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121
#6 0x00445d34 in reapchild (n=20) at main.c:5177
#7
#8 objlist_call_fini () at /usr/src/libexec/rtld-elf/rtld.c:769
#9 0x0008006a0c2b in rtld_exit () at /usr/src/libexec/rtld-elf/rtld.c:2710
#10 0x0008024e5406 in __cxa_finalize (dso=0x0)
at /usr/src/lib/libc/stdlib/atexit.c:200
#11 0x00080248692c in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:67
#12 0x00445f35 in Exit (n=0) at main.c:5078
#13 0x00456020 in Cleanup (code=0) at misc.c:5238
#14 0x0044da49 in NormalExit () at misc.c:5222
#15 0x0045a616 in readPtyData (xw=0x804cdc000, select_mask=0x6add80,
data=0x804d64000) at ptydata.c:221
#16 0x00421c48 in in_put (xw=0x804cdc000) at charproc.c:4700
#17 0x00421b6a in doinput () at charproc.c:4856
#18 0x0041d992 in VTparse (xw=0x804cdc000) at charproc.c:4382
#19 0x0041d87a in VTRun (xw=0x804cdc000) at charproc.c:6997
#20 0x00442c01 in main (argc=3, argv=0x7fffe6d0) at main.c:2607
#6 0x00445d34 in reapchild (n=20) at main.c:5177
5177pid = wait(NULL);
Current language: auto; currently minimal
(gdb) l
5172int olderrno = errno;
5173int pid;
5174
5175DEBUG_MSG("handle:reapchild\n");
5176
5177pid = wait(NULL);
5178
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Thu, Aug 27, 2015 at 08:53:09PM +0200, Michiel Boland wrote:
> The xterm program has a SIGCHLD signal handler that calls wait().
> If the handler is invoked while xterm is exiting, a deadlock occurs in rtld.
>
> Cheers
> Michiel
>
> #0 _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
> #1 0x00080305a2b0 in __thr_rwlock_rdlock (rwlock=0x803272980,
> flags=, tsp=)
> at /usr/src/lib/libthr/thread/thr_umtx.c:277
> #2 0x00080306179c in _thr_rtld_rlock_acquire (lock=0x803272980)
> at thr_umtx.h:196
Please from the frame 2, do p *curthread.
> #3 0x0008006a72c2 in rlock_acquire (lock=0x8008ba860,
> lockstate=0x7fffd5b8) at /usr/src/libexec/rtld-elf/rtld_lock.c:201
> #4 0x0008006a0c8d in _rtld_bind (obj=0x8006bc000, reloff=6840)
> at /usr/src/libexec/rtld-elf/rtld.c:701
> #5 0x00080069e46d in _rtld_bind_start ()
> at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:121
> #6 0x00445d34 in reapchild (n=20) at main.c:5177
> #7
It is more or less obvious that the reapchild(), which is the signal
handler, was called directly without a libthr thr_sighandler() wrapped
around it. This should be the cause of the problem.
I just verified that the signal handler is correctly wrapped for me, on
the latest stable/10. Both with the pre-linked libthr.so and with the
library loaded dynamically at runtime. I used the test program at the
end of the message, put breakpoint on the sigusr2_handler, and looked
at the backtrace, which must include thr_sighandler(). It did in my
case, for binary built with and without -lpthread.
Can you verify the presence of thr_sighandler() in the backtrace for
this test program, on your system ?
> #8 objlist_call_fini () at /usr/src/libexec/rtld-elf/rtld.c:769
> #9 0x0008006a0c2b in rtld_exit () at
> /usr/src/libexec/rtld-elf/rtld.c:2710
> #10 0x0008024e5406 in __cxa_finalize (dso=0x0)
> at /usr/src/lib/libc/stdlib/atexit.c:200
> #11 0x00080248692c in exit (status=0) at
> /usr/src/lib/libc/stdlib/exit.c:67
> #12 0x00445f35 in Exit (n=0) at main.c:5078
> #13 0x00456020 in Cleanup (code=0) at misc.c:5238
> #14 0x0044da49 in NormalExit () at misc.c:5222
> #15 0x0045a616 in readPtyData (xw=0x804cdc000, select_mask=0x6add80,
> data=0x804d64000) at ptydata.c:221
> #16 0x00421c48 in in_put (xw=0x804cdc000) at charproc.c:4700
> #17 0x00421b6a in doinput () at charproc.c:4856
> #18 0x0041d992 in VTparse (xw=0x804cdc000) at charproc.c:4382
> #19 0x0041d87a in VTRun (xw=0x804cdc000) at charproc.c:6997
> #20 0x00442c01 in main (argc=3, argv=0x7fffe6d0) at main.c:2607
>
> #6 0x00445d34 in reapchild (n=20) at main.c:5177
> 5177pid = wait(NULL);
> Current language: auto; currently minimal
> (gdb) l
> 5172int olderrno = errno;
> 5173int pid;
> 5174
> 5175DEBUG_MSG("handle:reapchild\n");
> 5176
> 5177pid = wait(NULL);
> 5178
/* $Id: rtld_sigresolv.c,v 1.6 2015/08/27 19:40:42 kostik Exp kostik $ */
/* /usr/local/opt/gcc-5.2.0/bin/gcc -Wall -Wextra -gdwarf-2 -O -o
rtld_sigresolv rtld_sigresolv.c */
#include
#include
#include
#include
#include
#include
#include
#include
static void
sigusr1_handler(int signo __unused, siginfo_t *si __unused, void *u __unused)
{
}
static void
sigusr2_handler(int signo __unused, siginfo_t *si __unused, void *u __unused)
{
/* Do something which triggers symbol resolution. */
wait(NULL);
}
static void
atexit_code(void)
{
raise(SIGUSR2);
}
static void *
dummy_thread(void *arg __unused)
{
return (NULL);
}
int
main(void)
{
struct sigaction sa;
void *thr_handle;
int (*pthr_create)(pthread_t *, const pthread_attr_t *,
void *(*)(void *), void *);
pthread_t pthread;
int error;
memset(&sa, 0, sizeof(sa));
sa.sa_flags = SA_SIGINFO;
sa.sa_sigaction = sigusr1_handler;
error = sigaction(SIGUSR1, &sa, NULL);
if (error != 0)
err(1, "sigaction SIGUSR1");
sa.sa_sigaction = sigusr2_handler;
error = sigaction(SIGUSR2, &sa, NULL);
if (error != 0)
err(1, "sigaction SIGUSR2");
raise(SIGUSR1); /* pre-resolve the raise symbol */
error = atexit(atexit_code);
if (error != 0)
err(1, "atexit");
thr_handle = dlopen("libpthread.so", RTLD_LAZY | RTLD_GLOBAL);
if (thr_handle == NULL)
errx(1, "dlopen(\"libpthread.so\"): %s", dlerror());
pthr_create = dlsym(thr_handle, "pthread_create");
if (pthr_create == NULL)
errx(1, "dlsym(\"pthread_create\"): %s", dlerror());
error = pthr_create(&pthread, NULL, dummy_thread, NULL);
if (error != 0)
errc(1, error, "pthread_create");
return (0);
}
_
Re: Latest stable (r287104) bash leaves zombies on exit
On 08/27/2015 22:16, Konstantin Belousov wrote: [...] I just verified that the signal handler is correctly wrapped for me, on the latest stable/10. Both with the pre-linked libthr.so and with the library loaded dynamically at runtime. I used the test program at the end of the message, put breakpoint on the sigusr2_handler, and looked at the backtrace, which must include thr_sighandler(). It did in my case, for binary built with and without -lpthread. Can you verify the presence of thr_sighandler() in the backtrace for this test program, on your system ? Verified, see below. Cheers Michiel Breakpoint 1, sigusr2_handler (signo=31, si=0x7fffe430, u=0x7fffe0c0) at rtld_sigresolv.c:24 24 wait(NULL); Current language: auto; currently minimal (gdb) bt #0 sigusr2_handler (signo=31, si=0x7fffe430, u=0x7fffe0c0) at rtld_sigresolv.c:24 #1 0x00080100d947 in handle_signal (actp=, sig=31, info=0x7fffe430, ucp=0x7fffe0c0) at /usr/src/lib/libthr/thread/thr_sig.c:243 #2 0x00080100d158 in thr_sighandler (sig=, info=, _ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:188 #3 #4 thr_kill () at thr_kill.S:3 #5 0x000800965066 in __raise (s=) at /usr/src/lib/libc/gen/raise.c:51 #6 0x00400c72 in atexit_code () at rtld_sigresolv.c:31 #7 0x00080093d406 in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:200 #8 0x0008008de92c in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:67 #9 0x00400946 in _start (ap=, cleanup=) at /usr/src/lib/csu/amd64/crt1.c:78 #10 0x000800621000 in ?? () #11 0x in ?? () ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Fri, Aug 28, 2015 at 08:08:27AM +0200, Michiel Boland wrote:
> On 08/27/2015 22:16, Konstantin Belousov wrote:
> [...]
> > I just verified that the signal handler is correctly wrapped for me, on
> > the latest stable/10. Both with the pre-linked libthr.so and with the
> > library loaded dynamically at runtime. I used the test program at the
> > end of the message, put breakpoint on the sigusr2_handler, and looked
> > at the backtrace, which must include thr_sighandler(). It did in my
> > case, for binary built with and without -lpthread.
> >
> > Can you verify the presence of thr_sighandler() in the backtrace for
> > this test program, on your system ?
>
> Verified, see below.
> Cheers
> Michiel
>
> Breakpoint 1, sigusr2_handler (signo=31, si=0x7fffe430, u=0x7fffe0c0)
> at rtld_sigresolv.c:24
> 24 wait(NULL);
> Current language: auto; currently minimal
> (gdb) bt
> #0 sigusr2_handler (signo=31, si=0x7fffe430, u=0x7fffe0c0)
> at rtld_sigresolv.c:24
> #1 0x00080100d947 in handle_signal (actp=, sig=31,
> info=0x7fffe430, ucp=0x7fffe0c0)
> at /usr/src/lib/libthr/thread/thr_sig.c:243
> #2 0x00080100d158 in thr_sighandler (sig=,
> info=, _ucp=)
> at /usr/src/lib/libthr/thread/thr_sig.c:188
> #3
I suppose this is with the binary built without -lpthread ?
I probably have an idea what is going wrong. Please try the patch
below. Libc does not used interposed sig{procmask,action,suspend}
entries itself, which resulted in e.g. signal(3) breaking libthr
hooks.
> #4 thr_kill () at thr_kill.S:3
> #5 0x000800965066 in __raise (s=)
> at /usr/src/lib/libc/gen/raise.c:51
> #6 0x00400c72 in atexit_code () at rtld_sigresolv.c:31
> #7 0x00080093d406 in __cxa_finalize (dso=0x0)
> at /usr/src/lib/libc/stdlib/atexit.c:200
> #8 0x0008008de92c in exit (status=0) at
> /usr/src/lib/libc/stdlib/exit.c:67
> #9 0x00400946 in _start (ap=,
> cleanup=) at /usr/src/lib/csu/amd64/crt1.c:78
> #10 0x000800621000 in ?? ()
> #11 0x in ?? ()
diff --git a/lib/libc/amd64/gen/setjmp.S b/lib/libc/amd64/gen/setjmp.S
index c26f52f..826220e 100644
--- a/lib/libc/amd64/gen/setjmp.S
+++ b/lib/libc/amd64/gen/setjmp.S
@@ -55,7 +55,7 @@ ENTRY(setjmp)
movq$0,%rsi /* (sigset_t*)set */
leaq72(%rcx),%rdx /* 9,10; (sigset_t*)oset */
/* stack is 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
popq%rdi
movq%rdi,%rcx
movq0(%rsp),%rdx/* retval */
@@ -82,7 +82,7 @@ ENTRY(__longjmp)
leaq72(%rdx),%rsi /* (sigset_t*)set */
movq$0,%rdx /* (sigset_t*)oset */
subq$0x8,%rsp /* make the stack 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
addq$0x8,%rsp
popq%rsi
popq%rdi/* jmpbuf */
diff --git a/lib/libc/amd64/gen/sigsetjmp.S b/lib/libc/amd64/gen/sigsetjmp.S
index 9a20556..1e8e77c 100644
--- a/lib/libc/amd64/gen/sigsetjmp.S
+++ b/lib/libc/amd64/gen/sigsetjmp.S
@@ -63,7 +63,7 @@ ENTRY(sigsetjmp)
movq$0,%rsi /* (sigset_t*)set */
leaq72(%rcx),%rdx /* 9,10 (sigset_t*)oset */
/* stack is 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
popq%rdi
2: movq%rdi,%rcx
movq0(%rsp),%rdx/* retval */
@@ -91,7 +91,7 @@ ENTRY(__siglongjmp)
leaq72(%rdx),%rsi /* (sigset_t*)set */
movq$0,%rdx /* (sigset_t*)oset */
subq$0x8,%rsp /* make the stack 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
addq$0x8,%rsp
popq%rsi
popq%rdi/* jmpbuf */
diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c
index 199846f..a8cef1c 100644
--- a/lib/libc/compat-43/sigcompat.c
+++ b/lib/libc/compat-43/sigcompat.c
@@ -59,7 +59,7 @@ sigvec(signo, sv, osv)
} else
sap = NULL;
osap = osv != NULL ? &osa : NULL;
- ret = _sigaction(signo, sap, osap);
+ ret = __libc_sigaction(signo, sap, osap);
if (ret == 0 && osv != NULL) {
osv->sv_handler = osa.sa_handler;
osv->sv_flags = osa.sa_flags ^ SV_INTERRUPT;
@@ -77,7 +77,7 @@ sigsetmask(mask)
sigemptyset(&set);
set.__bits[0] = mask;
- n = _sigprocmask(SIG_SETMASK, &set, &oset);
+ n = __libc_sigprocmask(SIG_SETMASK, &set, &oset);
if (n)
return (n);
return (oset.__bits[0]);
@@ -92,7 +92,7 @@ sigblock(mask)
sigemptyset(&set);
set.__bits[0] = mask;
- n = _sigprocmask(SIG_
Re: Latest stable (r287104) bash leaves zombies on exit
On 08/28/2015 12:01, Konstantin Belousov wrote:
[...]
I probably have an idea what is going wrong. Please try the patch
below. Libc does not used interposed sig{procmask,action,suspend}
entries itself, which resulted in e.g. signal(3) breaking libthr
hooks.
I'm trying now, and it did appear to get rid of the zombies.
Here's a quick test.
set -e
for a in `seq 1000`
do
echo -n "$a "
xterm -e ssh nonexisting
done
echo ""
(The idea here is that 'ssh nonexisting' should do some work and then exit,
"xterm -e false", etc. don't appear to trigger the bug.)
Prior to the patch, one of the xterms would hang after the counter reaches a
random (reasonably small) number.
After the patch the script runs till completion.
Cheers
Michiel
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Fri, Aug 28, 2015 at 05:52:42PM +0200, Michiel Boland wrote:
> set -e
> for a in `seq 1000`
> do
> echo -n "$a "
> xterm -e ssh nonexisting
> done
> echo ""
>
> (The idea here is that 'ssh nonexisting' should do some work and then exit,
> "xterm -e false", etc. don't appear to trigger the bug.)
>
> Prior to the patch, one of the xterms would hang after the counter reaches a
> random (reasonably small) number.
>
> After the patch the script runs till completion.
Thank you for testing. Funny detail is that your loop does not hangs for
me, I see flapping xterms until the completion. How many cpus does your
machine have ?
Below is a slightly improved version of the change, to avoid unnecessary
relocations. Would be good to rebuild the world and confirm that you
see no regression (the patch also affects rtld in some way).
diff --git a/lib/libc/amd64/gen/setjmp.S b/lib/libc/amd64/gen/setjmp.S
index c26f52f..826220e 100644
--- a/lib/libc/amd64/gen/setjmp.S
+++ b/lib/libc/amd64/gen/setjmp.S
@@ -55,7 +55,7 @@ ENTRY(setjmp)
movq$0,%rsi /* (sigset_t*)set */
leaq72(%rcx),%rdx /* 9,10; (sigset_t*)oset */
/* stack is 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
popq%rdi
movq%rdi,%rcx
movq0(%rsp),%rdx/* retval */
@@ -82,7 +82,7 @@ ENTRY(__longjmp)
leaq72(%rdx),%rsi /* (sigset_t*)set */
movq$0,%rdx /* (sigset_t*)oset */
subq$0x8,%rsp /* make the stack 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
addq$0x8,%rsp
popq%rsi
popq%rdi/* jmpbuf */
diff --git a/lib/libc/amd64/gen/sigsetjmp.S b/lib/libc/amd64/gen/sigsetjmp.S
index 9a20556..1e8e77c 100644
--- a/lib/libc/amd64/gen/sigsetjmp.S
+++ b/lib/libc/amd64/gen/sigsetjmp.S
@@ -63,7 +63,7 @@ ENTRY(sigsetjmp)
movq$0,%rsi /* (sigset_t*)set */
leaq72(%rcx),%rdx /* 9,10 (sigset_t*)oset */
/* stack is 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
popq%rdi
2: movq%rdi,%rcx
movq0(%rsp),%rdx/* retval */
@@ -91,7 +91,7 @@ ENTRY(__siglongjmp)
leaq72(%rdx),%rsi /* (sigset_t*)set */
movq$0,%rdx /* (sigset_t*)oset */
subq$0x8,%rsp /* make the stack 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
addq$0x8,%rsp
popq%rsi
popq%rdi/* jmpbuf */
diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c
index 199846f..a8cef1c 100644
--- a/lib/libc/compat-43/sigcompat.c
+++ b/lib/libc/compat-43/sigcompat.c
@@ -59,7 +59,7 @@ sigvec(signo, sv, osv)
} else
sap = NULL;
osap = osv != NULL ? &osa : NULL;
- ret = _sigaction(signo, sap, osap);
+ ret = __libc_sigaction(signo, sap, osap);
if (ret == 0 && osv != NULL) {
osv->sv_handler = osa.sa_handler;
osv->sv_flags = osa.sa_flags ^ SV_INTERRUPT;
@@ -77,7 +77,7 @@ sigsetmask(mask)
sigemptyset(&set);
set.__bits[0] = mask;
- n = _sigprocmask(SIG_SETMASK, &set, &oset);
+ n = __libc_sigprocmask(SIG_SETMASK, &set, &oset);
if (n)
return (n);
return (oset.__bits[0]);
@@ -92,7 +92,7 @@ sigblock(mask)
sigemptyset(&set);
set.__bits[0] = mask;
- n = _sigprocmask(SIG_BLOCK, &set, &oset);
+ n = __libc_sigprocmask(SIG_BLOCK, &set, &oset);
if (n)
return (n);
return (oset.__bits[0]);
@@ -105,7 +105,7 @@ sigpause(int mask)
sigemptyset(&set);
set.__bits[0] = mask;
- return (_sigsuspend(&set));
+ return (__libc_sigsuspend(&set));
}
int
@@ -113,11 +113,11 @@ xsi_sigpause(int sig)
{
sigset_t set;
- if (_sigprocmask(SIG_BLOCK, NULL, &set) == -1)
+ if (__libc_sigprocmask(SIG_BLOCK, NULL, &set) == -1)
return (-1);
if (sigdelset(&set, sig) == -1)
return (-1);
- return (_sigsuspend(&set));
+ return (__libc_sigsuspend(&set));
}
int
@@ -128,7 +128,7 @@ sighold(int sig)
sigemptyset(&set);
if (sigaddset(&set, sig) == -1)
return (-1);
- return (_sigprocmask(SIG_BLOCK, &set, NULL));
+ return (__libc_sigprocmask(SIG_BLOCK, &set, NULL));
}
int
@@ -138,7 +138,7 @@ sigignore(int sig)
bzero(&sa, sizeof(sa));
sa.sa_handler = SIG_IGN;
- return (_sigaction(sig, &sa, NULL));
+ return (__libc_sigaction(sig, &sa, NULL));
}
int
@@ -149,7 +149,7 @@ sigrelse(int sig)
sigemptyset(&set);
i
Re: Latest stable (r287104) bash leaves zombies on exit
On 08/28/2015 18:18, Konstantin Belousov wrote:
On Fri, Aug 28, 2015 at 05:52:42PM +0200, Michiel Boland wrote:
set -e
for a in `seq 1000`
do
echo -n "$a "
xterm -e ssh nonexisting
done
echo ""
(The idea here is that 'ssh nonexisting' should do some work and then exit,
"xterm -e false", etc. don't appear to trigger the bug.)
Prior to the patch, one of the xterms would hang after the counter reaches a
random (reasonably small) number.
After the patch the script runs till completion.
Thank you for testing. Funny detail is that your loop does not hangs for
me, I see flapping xterms until the completion. How many cpus does your
machine have ?
I have a Q8300 (4 cpus) - I guess the timing matters.
Do I understand correctly that the problem is that if you install a signal
handler with signal() (which is what xterm does) and pull in libthr.so somehow,
then there is no thr_sighandler inserted?
I condensed the xterm problem into a small C program. Compile in such a way that
the delay loop does not get optimized out, and link with -lpthread. Eventually,
when executed often enough, this will hang in the same fashion as xterm does.
#include
#include
#include
#include
#include
#include
#include
static void reapchild(int sig __unused)
{
wait(NULL);
}
static void delay(void)
{
long i, n;
n = random() % 100;
if (n < 0) {
n = -n;
}
for (i = 0; i < n; i++)
;
}
int main()
{
int p[2];
char dummy;
srandomdev();
if (signal(SIGCHLD, reapchild) == SIG_ERR) {
perror("signal");
exit(1);
}
if (pipe(p) == -1) {
perror("pipe");
exit(1);
}
switch (fork()) {
case -1:
perror("fork");
exit(1);
case 0:
close(p[1]);
read(p[0], &dummy, 1);
_exit(0);
}
close(p[1]);
read(p[0], &dummy, 1);
delay();
exit(0);
}
Below is a slightly improved version of the change, to avoid unnecessary
relocations. Would be good to rebuild the world and confirm that you
see no regression (the patch also affects rtld in some way).
Ok, I will try this patch later today.
Cheers,
Michiel
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Sat, Aug 29, 2015 at 01:43:36PM +0200, Michiel Boland wrote: > Do I understand correctly that the problem is that if you install a signal > handler with signal() (which is what xterm does) and pull in libthr.so > somehow, > then there is no thr_sighandler inserted? Yes. The problem does not exist for the sigaction(2). ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Fri, Aug 28, 2015 at 07:18:47PM +0300, Konstantin Belousov wrote: > On Fri, Aug 28, 2015 at 05:52:42PM +0200, Michiel Boland wrote: > > set -e > > for a in `seq 1000` > > do > > echo -n "$a " > > xterm -e ssh nonexisting > > done > > echo "" > > (The idea here is that 'ssh nonexisting' should do some work and then exit, > > "xterm -e false", etc. don't appear to trigger the bug.) > > Prior to the patch, one of the xterms would hang after the counter > > reaches a random (reasonably small) number. > > After the patch the script runs till completion. > Thank you for testing. Funny detail is that your loop does not hangs for > me, I see flapping xterms until the completion. How many cpus does your > machine have ? > Below is a slightly improved version of the change, to avoid unnecessary > relocations. Would be good to rebuild the world and confirm that you > see no regression (the patch also affects rtld in some way). Looks good to me, except that I think a vforked child (in system() and posix_spawn*()) should use the system calls and not libthr's wrappers. This reduces the probability of weird things happening between vfork and exec, and also avoids an unexpected error when posix_spawnattr_setsigdefault()'s mask contains SIGTHR. -- Jilles Tjoelker ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Sat, Aug 29, 2015 at 03:01:38PM +0200, Jilles Tjoelker wrote:
> Looks good to me, except that I think a vforked child (in system() and
> posix_spawn*()) should use the system calls and not libthr's wrappers.
> This reduces the probability of weird things happening between vfork and
> exec, and also avoids an unexpected error when
> posix_spawnattr_setsigdefault()'s mask contains SIGTHR.
Thank you for the review, I agree with the note about vfork. Updated
patch is below. Also, I removed the PIC_PROLOGUE from the i386 setjmp,
it has no use after the plt calls are removed.
diff --git a/lib/libc/amd64/gen/setjmp.S b/lib/libc/amd64/gen/setjmp.S
index c26f52f..826220e 100644
--- a/lib/libc/amd64/gen/setjmp.S
+++ b/lib/libc/amd64/gen/setjmp.S
@@ -55,7 +55,7 @@ ENTRY(setjmp)
movq$0,%rsi /* (sigset_t*)set */
leaq72(%rcx),%rdx /* 9,10; (sigset_t*)oset */
/* stack is 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
popq%rdi
movq%rdi,%rcx
movq0(%rsp),%rdx/* retval */
@@ -82,7 +82,7 @@ ENTRY(__longjmp)
leaq72(%rdx),%rsi /* (sigset_t*)set */
movq$0,%rdx /* (sigset_t*)oset */
subq$0x8,%rsp /* make the stack 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
addq$0x8,%rsp
popq%rsi
popq%rdi/* jmpbuf */
diff --git a/lib/libc/amd64/gen/sigsetjmp.S b/lib/libc/amd64/gen/sigsetjmp.S
index 9a20556..1e8e77c 100644
--- a/lib/libc/amd64/gen/sigsetjmp.S
+++ b/lib/libc/amd64/gen/sigsetjmp.S
@@ -63,7 +63,7 @@ ENTRY(sigsetjmp)
movq$0,%rsi /* (sigset_t*)set */
leaq72(%rcx),%rdx /* 9,10 (sigset_t*)oset */
/* stack is 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
popq%rdi
2: movq%rdi,%rcx
movq0(%rsp),%rdx/* retval */
@@ -91,7 +91,7 @@ ENTRY(__siglongjmp)
leaq72(%rdx),%rsi /* (sigset_t*)set */
movq$0,%rdx /* (sigset_t*)oset */
subq$0x8,%rsp /* make the stack 16-byte aligned */
- callPIC_PLT(CNAME(_sigprocmask))
+ call__libc_sigprocmask
addq$0x8,%rsp
popq%rsi
popq%rdi/* jmpbuf */
diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c
index 199846f..a8cef1c 100644
--- a/lib/libc/compat-43/sigcompat.c
+++ b/lib/libc/compat-43/sigcompat.c
@@ -59,7 +59,7 @@ sigvec(signo, sv, osv)
} else
sap = NULL;
osap = osv != NULL ? &osa : NULL;
- ret = _sigaction(signo, sap, osap);
+ ret = __libc_sigaction(signo, sap, osap);
if (ret == 0 && osv != NULL) {
osv->sv_handler = osa.sa_handler;
osv->sv_flags = osa.sa_flags ^ SV_INTERRUPT;
@@ -77,7 +77,7 @@ sigsetmask(mask)
sigemptyset(&set);
set.__bits[0] = mask;
- n = _sigprocmask(SIG_SETMASK, &set, &oset);
+ n = __libc_sigprocmask(SIG_SETMASK, &set, &oset);
if (n)
return (n);
return (oset.__bits[0]);
@@ -92,7 +92,7 @@ sigblock(mask)
sigemptyset(&set);
set.__bits[0] = mask;
- n = _sigprocmask(SIG_BLOCK, &set, &oset);
+ n = __libc_sigprocmask(SIG_BLOCK, &set, &oset);
if (n)
return (n);
return (oset.__bits[0]);
@@ -105,7 +105,7 @@ sigpause(int mask)
sigemptyset(&set);
set.__bits[0] = mask;
- return (_sigsuspend(&set));
+ return (__libc_sigsuspend(&set));
}
int
@@ -113,11 +113,11 @@ xsi_sigpause(int sig)
{
sigset_t set;
- if (_sigprocmask(SIG_BLOCK, NULL, &set) == -1)
+ if (__libc_sigprocmask(SIG_BLOCK, NULL, &set) == -1)
return (-1);
if (sigdelset(&set, sig) == -1)
return (-1);
- return (_sigsuspend(&set));
+ return (__libc_sigsuspend(&set));
}
int
@@ -128,7 +128,7 @@ sighold(int sig)
sigemptyset(&set);
if (sigaddset(&set, sig) == -1)
return (-1);
- return (_sigprocmask(SIG_BLOCK, &set, NULL));
+ return (__libc_sigprocmask(SIG_BLOCK, &set, NULL));
}
int
@@ -138,7 +138,7 @@ sigignore(int sig)
bzero(&sa, sizeof(sa));
sa.sa_handler = SIG_IGN;
- return (_sigaction(sig, &sa, NULL));
+ return (__libc_sigaction(sig, &sa, NULL));
}
int
@@ -149,7 +149,7 @@ sigrelse(int sig)
sigemptyset(&set);
if (sigaddset(&set, sig) == -1)
return (-1);
- return (_sigprocmask(SIG_UNBLOCK, &set, NULL));
+ return (__libc_sigprocmask(SIG_UNBLOCK, &set, NULL));
}
void
@@ -161,26 +161,26 @@ void
sigemptyset(&set);
if (sigadd
Re: Latest stable (r287104) bash leaves zombies on exit
On 08/29/2015 15:41, Konstantin Belousov wrote: On Sat, Aug 29, 2015 at 03:01:38PM +0200, Jilles Tjoelker wrote: Looks good to me, except that I think a vforked child (in system() and posix_spawn*()) should use the system calls and not libthr's wrappers. This reduces the probability of weird things happening between vfork and exec, and also avoids an unexpected error when posix_spawnattr_setsigdefault()'s mask contains SIGTHR. Thank you for the review, I agree with the note about vfork. Updated patch is below. Also, I removed the PIC_PROLOGUE from the i386 setjmp, it has no use after the plt calls are removed. I verified the patch. The getumask part of lib/libc/gen/setmode.c part was rejected on stable/10 (probably due to other changes in ^/head.) Cheers Michiel ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Sat, Aug 29, 2015 at 04:02:43PM +0200, Michiel Boland wrote: > I verified the patch. The getumask part of lib/libc/gen/setmode.c part was > rejected on stable/10 (probably due to other changes in ^/head.) Thank you. The setmode bits are from the Jilles' r280713. I will merge this revision when doing the MFC, unless Jilles do it first. The change is committed to HEAD as r287292, MFC set to 1 week. I will ask for EN after merge to stable/10. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Latest stable (r287104) bash leaves zombies on exit
On Sat, Aug 29, 2015 at 04:41:30PM +0300, Konstantin Belousov wrote:
> On Sat, Aug 29, 2015 at 03:01:38PM +0200, Jilles Tjoelker wrote:
> > Looks good to me, except that I think a vforked child (in system() and
> > posix_spawn*()) should use the system calls and not libthr's wrappers.
> > This reduces the probability of weird things happening between vfork and
> > exec, and also avoids an unexpected error when
> > posix_spawnattr_setsigdefault()'s mask contains SIGTHR.
> Thank you for the review, I agree with the note about vfork. Updated
> patch is below. Also, I removed the PIC_PROLOGUE from the i386 setjmp,
> it has no use after the plt calls are removed.
> [snip]
> diff --git a/lib/libc/gen/posix_spawn.c b/lib/libc/gen/posix_spawn.c
> index e3124b2..673c760 100644
> --- a/lib/libc/gen/posix_spawn.c
> +++ b/lib/libc/gen/posix_spawn.c
> @@ -118,15 +118,18 @@ process_spawnattr(const posix_spawnattr_t sa)
> return (errno);
> }
>
> - /* Set signal masks/defaults */
> + /*
> + * Set signal masks/defaults.
> + * Use unwrapped syscall, libthr is in undefined state after vfork().
> + */
> if (sa->sa_flags & POSIX_SPAWN_SETSIGMASK) {
> - _sigprocmask(SIG_SETMASK, &sa->sa_sigmask, NULL);
> + __libc_sigprocmask(SIG_SETMASK, &sa->sa_sigmask, NULL);
> }
>
> if (sa->sa_flags & POSIX_SPAWN_SETSIGDEF) {
> for (i = 1; i <= _SIG_MAXSIG; i++) {
> if (sigismember(&sa->sa_sigdefault, i))
> - if (_sigaction(i, &sigact, NULL) != 0)
> + if (__libc_sigaction(i, &sigact, NULL) != 0)
> return (errno);
> }
> }
Hmm, the comments say direct syscalls are being used, but in fact
libthr's interposer is called. The change to system() does correctly use
__sys_sigprocmask().
--
Jilles Tjoelker
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
