Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14691 > unrolled thread

Re: Segfault on recursive trap/kill

Started byMike Gerwitz <mtg@gnu.org>
First post2018-10-06 19:53 -0400
Last post2018-10-06 19:53 -0400
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Segfault on recursive trap/kill Mike Gerwitz <mtg@gnu.org> - 2018-10-06 19:53 -0400

#14691 — Re: Segfault on recursive trap/kill

FromMike Gerwitz <mtg@gnu.org>
Date2018-10-06 19:53 -0400
SubjectRe: Segfault on recursive trap/kill
Message-ID<mailman.1777.1538870104.1284.bug-bash@gnu.org>

[Multipart message — attachments visible in raw view] — view raw

On Sat, Oct 06, 2018 at 12:33:22 -0400, Chet Ramey wrote:
> On 10/5/18 9:33 PM, Mike Gerwitz wrote:
>> The following code will cause a segfault on bash-4.4.19(1) on
>> GNU Guix.  I reproduced the issue on an old Ubuntu 14.04 LTS running
>> bash-4.3.11(1) as well as a Trisquel system running the same version.
>> 
>>   bash -c 'trap "kill 0" TERM; kill 0'
>> 
>> Also segfaults when replacing `0' with `$$', and presumably in any other
>> situation that would trigger the trap recursively.
>
> Yes. Bash has allowed recursive trap handlers since early 2014 (pre-4.3)
> due to requests for the feature and compatibility with other shells that
> allow it.
>
> If you manage to create infinite recursion, bash won't stop you.

Sure, I agree that the feature is useful, but are you saying that
terminating with a segfault is the intended behavior for runaway
recursion?  Upon further inspection, it does look like
`foo() { foo; }; foo' also causes a segfault, so the behavior is
consistent with trap recursion.

As long as there is no exploitable flaw here, then I suppose this isn't
a problem; it's just that most users assume that a segfault represents a
problem with the program (unless they're dealing with their own memory
management).  I haven't inspected the code to see if this is an access
violation or if Bash is intentionally signaling SIGSEGV.

In any case, thanks for the reply.

-- 
Mike Gerwitz

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web