> 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.
> 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.
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
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.
> >
> > 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:
>
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."
>
> 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
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
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
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
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
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
12 matches
Mail list logo