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


Groups > gnu.bash.bug > #16568

Re: Segfault in Bash

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: Segfault in Bash
Date 2020-07-14 09:08 -0400
Organization ITS, Case Western Reserve University
Message-ID <mailman.192.1594732136.2306.bug-bash@gnu.org> (permalink)
References <CAH8yC8nB5fhvvdD1bCUsgNzNTni4ixkjDbfeKQLNVqZ71HpxBg@mail.gmail.com> <000a9512-7179-1379-4df0-ff256a105580@case.edu>

Show all headers | View raw


On 7/14/20 6:32 AM, Jeffrey Walton wrote:
> Hi Everyone,
> 
> I'm working on a script to find all shared objects in a directory. A
> filename should match the RE '*.so$'. I thought I would pipe it to
> grep:
> 
> $ ./audit-libs.sh /home/jwalton/tmp/ok2delete/lib
> ./audit-libs.sh: line 17: 22929 Segmentation fault      (core dumped)
> $(echo "$file" | grep -E "*.so$")
> ./audit-libs.sh: line 17: 22934 Segmentation fault      (core dumped)
> $(echo "$file" | grep -E "*.so$")
> ./audit-libs.sh: line 17: 22939 Segmentation fault      (core dumped)
> $(echo "$file" | grep -E "*.so$")
> ...
> 
> My code is broken at the moment. I know I am the cause of Bash's
> crash. But I feel like Bash should not segfault.

Bash is reporting that a process exited due to a seg fault, but it is
not necessarily a bash process.

Since the message is reporting a core dump, a backtrace from that would
tell you what's faulting.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

Re: Segfault in Bash Chet Ramey <chet.ramey@case.edu> - 2020-07-14 09:08 -0400

csiph-web