Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread konsolebox
> OK. What version of Linux are you using? Maybe I have that and will be > able to reproduce it more easily. > > Chet > Oh sorry, if you mean the kernel version it's 3.4.10-tuxonice in Gentoo but it happens in most if not all kernels I used. Glibc version is 2.15-r2.

Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread konsolebox
> OK. What version of Linux are you using? Maybe I have that and will be > able to reproduce it more easily. > > Chet > Gentoo, but it happens in Slackware as well. Ubuntu too I think.

Re: [PATCH] Fix several missing close() calls.

2013-01-24 Thread Chet Ramey
On 1/24/13 5:53 PM, Roman Rakus wrote: > There are missing calls of close() leading to resource leak (fd leak). Thanks for the report and fix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc

[PATCH] Fix several missing close() calls.

2013-01-24 Thread Roman Rakus
There are missing calls of close() leading to resource leak (fd leak). Simple reproducer: . / and /proc/$$/fd contain one open fd for each above call Signed-off-by: Roman Rakus --- builtins/evalfile.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/builtins/evalfile.c b/builtins/evalfile.

Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread Chet Ramey
> > > > This doesn't help a lot. How about building bash-4.2.42 with -g so > > debugging symbols are preserved, then seeing where the crash is? > > > > I compiled 4.2.42 using gcc 4.6.3 (C[XX]FLAGS="-march=native -O2 -g"). It > took longer before the crash occurred and this is the report I got: >

Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread Andreas Schwab
I'd suggest to also try valgrind. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread konsolebox
> > This doesn't help a lot. How about building bash-4.2.42 with -g so > debugging symbols are preserved, then seeing where the crash is? > I compiled 4.2.42 using gcc 4.6.3 (C[XX]FLAGS="-march=native -O2 -g"). It took longer before the crash occurred and this is the report I got: malloc: ./read

Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread Chet Ramey
On 1/24/13 11:32 AM, konsolebox wrote: > Hi. Thanks for the attention. Here's a backtrace: This doesn't help a lot. How about building bash-4.2.42 with -g so debugging symbols are preserved, then seeing where the crash is? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer

Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread konsolebox
Hi. Thanks for the attention. Here's a backtrace: summon. : disown. read. *** glibc detected *** /bin/bash: double free or corruption (fasttop): 0x006caa60 *** Program received signal SIGSEGV, Segmentation fault. 0x7740c685 in ?? () from /lib64/libc.so.6 (gdb) bt #0 0x774

Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread lina
On Friday 25,January,2013 12:28 AM, Chet Ramey wrote: > On 1/24/13 8:35 AM, konsolebox wrote: >> Hi. Is there a way to prevent this segmentation fault in Bash? I'm not sure >> where the fault happens but when there's a function that handles a trap and >> when a signal is caught during a session of

Re: Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread Chet Ramey
On 1/24/13 8:35 AM, konsolebox wrote: > Hi. Is there a way to prevent this segmentation fault in Bash? I'm not sure > where the fault happens but when there's a function that handles a trap and > when a signal is caught during a session of read with -t, Bash crashes. An > example code that makes th

Bash crashes with trapped SIGCHLD and read -t.

2013-01-24 Thread konsolebox
Hi. Is there a way to prevent this segmentation fault in Bash? I'm not sure where the fault happens but when there's a function that handles a trap and when a signal is caught during a session of read with -t, Bash crashes. An example code that makes this happen is this: #!/b