From: Vladimir T. <vtz...@gm...> - 2009-10-22 17:49:06
|
Sam, I observe that sometimes clisp process hangs during the build and traced it to following (all this happens only on osx - 10.4,10.5,10.6 - with mt and generational GC): vtzankov:m32-3 vtz$ ./clisp --version | head -n 1 GNU CLISP 2.48+ (2009-08-24) (built 3465206612) (memory 3465206656) and in another terminal vtzankov:~ vtz$ ps | grep lisp 91778 s001 S+ 0:00.03 /Users/vtz/clisp/dev/m32-3/base/lisp.run -B /Users/vtz/clisp/dev/m32-3 -M /Users/vtz/clisp/dev/m32-3/base/lispinit.mem -N /Users/vtz/clisp/dev/m32-3/locale --version 91786 s003 S+ 0:00.00 grep lisp vtzankov:~ vtz$ gdb GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul 3 01:19:56 UTC 2009) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin". (gdb) attach 91778 Attaching to process 91778. Reading symbols for shared libraries . done Reading symbols for shared libraries ..... done 0x93fc313a in __sigwait () (gdb) info threads 3 port# 0x111b hashcode1stable (obj=0x1a279ec9) at hashtabl.d:160 2 port# 0x1003 0x0001d10d in sigpipe_handler (sig=13) at spvw_sigpipe.d:41 * 1 port# 0x60f 0x93fc313a in __sigwait () (gdb) thread 2 [Switching to thread 2 (process 91778)] 0x0001d10d in sigpipe_handler (sig=13) at spvw_sigpipe.d:41 41 if (writing_to_subprocess) (gdb) where #0 0x0001d10d in sigpipe_handler (sig=13) at spvw_sigpipe.d:41 #1 <signal handler called> #2 0x93f568da in mach_msg_trap () #3 0x93f57047 in mach_msg () #4 0x0014f684 in mach_exception_thread (arg=0x0) at handler-macos.c:344 #5 0x93f83fbd in _pthread_start () #6 0x93f83e42 in thread_start () As it appears SIGPIPE is delivered to libsigsegv thread and there is no valid writing_to_subprocess (there is no lisp thread allocated at all for this thread) - segfault happens (with bonus deadlock). I do not a see reason for this. This thread does not perform any I/O in order to get the signal. Attached patch fixes the problem but I do not like it - it's just workaround. Should I commit it? Vladimir --- spvw_sigpipe.d 2009-10-22 16:50:26.000000000 +0300 +++ ../../cvs/src/spvw_sigpipe.d 2009-10-09 09:04:46.000000000 +0300 @@ -38,10 +38,6 @@ local void sigpipe_handler (int sig) { signal_acknowledge(SIGPIPE,&sigpipe_handler); -#if defined(MULTITHREAD) && defined(UNIX_MACOSX) && defined(GENERATIONAL_GC) - if (!current_thread()) - return; -#endif if (writing_to_subprocess) /* Ignore the signal, the write() error code is sufficient. */ return; |
From: Sam S. <sd...@gn...> - 2009-10-22 19:57:52
|
Vladimir, Vladimir Tzankov wrote: > > I observe that sometimes clisp process hangs during the build and > traced it to following (all this happens only on osx - 10.4,10.5,10.6 > - with mt and generational GC): what does this have to do with "closed stdout"? you mention it only in the subject > As it appears SIGPIPE is delivered to libsigsegv thread and there is where is this signal coming from? > no valid writing_to_subprocess (there is no lisp thread allocated at > all for this thread) - segfault happens (with bonus deadlock). I do > not a see reason for this. This thread does not perform any I/O in > order to get the signal. can it be somehow related to gengc paging operations? > Attached patch fixes the problem but I do not like it - it's just workaround. > Should I commit it? I am somewhat afraid that this just hides the real problem. why would current_thread fail? Bruno? > --- spvw_sigpipe.d 2009-10-22 16:50:26.000000000 +0300 > +++ ../../cvs/src/spvw_sigpipe.d 2009-10-09 09:04:46.000000000 +0300 > @@ -38,10 +38,6 @@ > local void sigpipe_handler (int sig) > { > signal_acknowledge(SIGPIPE,&sigpipe_handler); > -#if defined(MULTITHREAD) && defined(UNIX_MACOSX) && defined(GENERATIONAL_GC) > - if (!current_thread()) > - return; > -#endif > if (writing_to_subprocess) > /* Ignore the signal, the write() error code is sufficient. */ > return; |
From: Vladimir T. <vtz...@gm...> - 2009-10-22 21:03:38
|
> what does this have to do with "closed stdout"? > you mention it only in the subject ./clisp --version | head -n 1 stdout is closed after the first line is read by head. >> As it appears SIGPIPE is delivered to libsigsegv thread and there is > > where is this signal coming from? That's what bothers me too. There is no reason SIGPIPE to be delivered to libsigsegv thread. > can it be somehow related to gengc paging operations? I don't think so. >> Attached patch fixes the problem but I do not like it - it's just >> workaround. >> Should I commit it? > > I am somewhat afraid that this just hides the real problem. Me too. > why would current_thread fail? current_thread() has value only for lisp threads. On osx, libsigsegv creates thread listening for segafaults and it does not have associated clisp_thread_t struct. So it should not reference any globals (and does not do i/o - no reason to get SIGPIPE). Vladimir |
From: Sam S. <sd...@gn...> - 2009-10-26 14:53:22
|
Vladimir Tzankov wrote: >> what does this have to do with "closed stdout"? >> you mention it only in the subject > > ./clisp --version | head -n 1 > stdout is closed after the first line is read by head. aha! so maybe stream.d:init_streamvars should detect that stdout/stdin/stderr is a pipe (using stream.d:pipe_handle_type_p) and set writing_to_process to true? |
From: Vladimir T. <vtz...@gm...> - 2009-10-26 20:47:35
|
On 10/26/09, Sam Steingold <sd...@gn...> wrote: > Vladimir Tzankov wrote: >>> what does this have to do with "closed stdout"? >>> you mention it only in the subject >> >> ./clisp --version | head -n 1 >> stdout is closed after the first line is read by head. > > aha! > so maybe stream.d:init_streamvars should detect that stdout/stdin/stderr is a > pipe (using stream.d:pipe_handle_type_p) and set writing_to_process to true? While this will solve this particular problem it may bring it's own ones (at least rebinding/setf-ing *standard-output* will leave writing_to_subprocess true). The real problem is why SIGPIPE is delivered to libsigsegv thread? I think it's osx issue - SIGPIPE is synchronous, occurs only during write() and is delivered in thread causing it - I do not understand why it goes to libsigsegv thread. |