I really appreciate that. Thank you very much :)
My software would finally work in a loop with no worries.
OK, I was able to figure it out. The problem is that the `read -t'
> generates SIGALRM, which sometimes arrives and is handled while the SIGCHLD
> trap is running (bash-4.2 runs the SIGCHLD
On 1/24/13 12:10 PM, konsolebox wrote:
> 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 oc
> 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.
> >
> > 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
11 matches
Mail list logo
