problem with mt, libsigsegv and closed stdout on osx

[Vladimir Tzankov]

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;

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Sam Steingold]

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;

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Vladimir Tzankov]

> 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

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Sam Steingold]

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?

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[Vladimir Tzankov]

On 10/26/09, Sam Steingold <sds@...> 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.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
clisp-devel mailing list
clisp-devel@...
https://lists.sourceforge.net/lists/listinfo/clisp-devel