This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [Bug-readline] [readline patch, gdb-7.3?] Avoid free from a signal handler [Re: [PATCH] Make interrupting tab-completion safe.]
- From: Chet Ramey <chet dot ramey at case dot edu>
- To: jan dot kratochvil at redhat dot com
- Cc: chet dot ramey at case dot edu, bug-readline at gnu dot org, gdb-patches at sourceware dot org, saugustine at google dot com, chet at po dot cwru dot edu
- Date: Wed, 6 Jul 2011 11:58:26 -0400
- Subject: Re: [Bug-readline] [readline patch, gdb-7.3?] Avoid free from a signal handler [Re: [PATCH] Make interrupting tab-completion safe.]
- Read-receipt-to: chet.ramey@case.edu
- References: <BANLkTikW2qaihdZ2zGxx6K+4q8eGzFZOr3mcbPdZsJ+2Ra=YXQ@mail.gmail.com> <20110612121158.GA10611@host1.jankratochvil.net> <BANLkTik1Z5GoCjNP9enPJeLThVk=g9Aj5ZF6zeDULburd2w=bw@mail.gmail.com> <20110626222146.GA4410@host1.jankratochvil.net> <4E0B2E83.9030202@case.edu> <20110629203457.GA28353@host1.jankratochvil.net> <4E0C8A5D.7000807@case.edu> <20110706154621.GA17142@host1.jankratochvil.net>
- Reply-to: chet dot ramey at case dot edu
> On Thu, 30 Jun 2011 16:38:21 +0200, Chet Ramey wrote:
> > I have seen cases where the user hits ^C while readline or a filename
> > completion function is attempting to traverse a file system on a dead
> > NFS server, the signal handler gets hit, but the system call doesn't
> > get interrupted. I haven't seen those cases in a while, though.
>
> I have tried to reproduce it but I think it is outside of the scope of
> readline and/or gdb.
>
> Running
> ip6tables -I INPUT 1 -i lo -p tcp --dport 2049 -j DROP
> before rl_filename_completion_function's readdir() call will cause (in strace):
>
> rt_sigaction(SIGINT, {0x6518cb=handle_sigint, [INT], SA_RESTORER|SA_RESTART, 0x7f79cf0bd490}, NULL, 8) = 0
> rt_sigaction(SIGQUIT, {0x65196e=handle_sigquit, [QUIT], SA_RESTORER|SA_RESTART, 0x7f79cf0bd490}, NULL, 8) = 0
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> [...]
> getdents(5, <hang>
>
> and no CTRL-C makes any change. It was mounted
> on kernel-2.6.35.13-92.fc14.x86_64 with options:
> localhost:/... /... nfs ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,soft,proto=tcp6,timeo=600,retrans=2,sec=sys,mountaddr=::1,mountvers=3,mountport=59099,mountproto=udp6,addr=::1 0 0
>
> where I used "intr" but "intr" / "nointr" is not listed at all and man says:
> The intr / nointr mount option is deprecated after kernel 2.6.25.
> Only SIGKILL can interrupt a pending NFS operation on these kernels,
> and if specified, this mount option is ignored to provide backwards
> compatibility with older kernels.
Other systems besides Linux still implement the `intr' mount option and
allow system calls referencing unresponsive remote file systems to be
interrupted (FreeBSD and Mac OS X, for example). I'm willing to accept
that bugs in prior versions of these systems have been fixed and the
options work as documented.
> > remove the references to _rl_interrupt_immediately
>
> I think _rl_interrupt_immediately should never exist as you cannot do anything
> much from the signal handler anyway.
> man 7 signak "Async-signal-safe functions"
If you believe that you either have no hope (can't interrupt an operation on
an unresponsive server) or will get proper EINTR behavior, then you are right.
Otherwise, it's your only chance.
As I said, I'm willing to remove these references and see what happens. Since
you have a way to readily reproduce the problem, I was hoping you'd do it
and let me know what you found.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/