This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Why SIGABRT
- From: Joël Krähemann <weedlight at gmail dot com>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: libc-help <libc-help at sourceware dot org>
- Date: Tue, 19 Aug 2014 01:47:57 +0200
- Subject: Re: Why SIGABRT
- Authentication-results: sourceware.org; auth=none
- References: <CANr2zYjVgOea-tShj_UTmpq=N_Avb2LdGUOdrgOHTymGJ=MzWw at mail dot gmail dot com> <CAAHN_R1M1MC3fur5Xji0V7VdqW9akLS6Q=oj1gBN4nYTWJG-Ag at mail dot gmail dot com>
Am Mittwoch, den 02.07.2014, 16:44 +0530 schrieb Siddhesh Poyarekar:
> On 2 July 2014 16:35, JoÃl KrÃhemann <weedlight@gmail.com> wrote:
> > Hi, my name is JoÃl KrÃhemann and I'm developing Advanced Gtk+
> > Sequencer. I get the following backtrace out of gdb. `ags` should be
> > thread safe so perhaps it's more related to glib and the root cause
> > may be line 4 and: have_lock=0
> >
> > I'll read the source code of glib for further investigation, assumed
> > someone knows the problem it would be nice to know it.
>
> The problem here is that there was a memory corruption which free
> detected and hence aborted. The memory corruption could have happened
> anywhere in the program; a tool like valgrind may help uncover the
> root cause.
>
> > What about ignoring SIGABRT?
>
> You can ignore SIGABRT by exporting MALLOC_CHECK_ (the trailing
> underscore is not a typo) to 0, but that is just papering over the
> memory corruption.
>
> Siddhesh
>
> >
> > 7fff937d0000-7fff93fd0000 rw-p 00000000 00:00 0
> > 7fff93fd0000-7fff93fd1000 ---p 00000000 00:00 0
> > 7fff93fd1000-7fff947d1000 rw-p 00000000 00:00 0
> > 7fff947d1000-7fff947d2000 ---p 00000000 00:00 0
> > 7fff947d2000-7fff94fd2000 rw-p 00000000 00:00 0
> > 7fff94fd2000-7fff94fd3000 ---p 00000000 00:00 0
> > 7fff94fd3000-7fff957d3000 rw-p 00000000 00:00 0
> > 7fff957d3000-7fff957d4000 ---p 00000000 00:00 0
> > 7fff957d4000-7fff95fd4000 rw-p 00000000 00:00 0
> > 7fff95fd4000-7fff95fd5000 ---p 00000000 00:00 0
> > 7fff95fd5000-7fff967d5000 rw-p 00000000 00:00 0
> > Program received signal SIGABRT, Aborted.
> > [Switching to Thread 0x7fffeec86700 (LWP 15013)]
> > 0x00007ffff0303349 in __GI_raise (sig=sig@entry=6) at
> > ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> > 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> > (gdb) make ags
> > (gdb) bt
> > #0 0x00007ffff0303349 in __GI_raise (sig=sig@entry=6) at
> > ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> > #1 0x00007ffff0304748 in __GI_abort () at abort.c:89
> > #2 0x00007ffff03411d4 in __libc_message
> > (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff04334b8 "*** Error in
> > `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
> > #3 0x00007ffff034695e in malloc_printerr (action=3,
> > str=0x7ffff042f608 "free(): invalid size", ptr=<optimized out>) at
> > malloc.c:4991
> > #4 0x00007ffff0347666 in _int_free (av=<optimized out>,
> > p=<optimized out>, have_lock=0) at malloc.c:3837
> > #5 0x00007ffff290dec8 in g_free () from
> > /usr/lib/../lib64/libglib-2.0.so.0
> > #6 0x00007ffff2902518 in g_list_foreach () from
> > /usr/lib/../lib64/libglib-2.0.so.0
> > #7 0x00007ffff2901ac8 in g_list_free_full () from
> > /usr/lib/../lib64/libglib-2.0.so.0
> > #8 0x000000000046a74f in ags_audio_signal_finalize
> > (gobject=0x7fffdc18adc0) at ./src/ags/audio/ags_audio_signal.c:329
> > #9 0x00007ffff2df1282 in g_object_unref () from
> > /usr/lib/../lib64/libgobject-2.0.so.0
> > #10 0x000000000046c752 in
> > ags_recall_recycling_set_property (gobject=0x7fffdc793cf0,
> > prop_id=<optimized out>, value=0x7fffeec83d50,
> > param_spec=0x7fffe17ed280) at
> > ./src/ags/audio/ags_recall_recycling.c:367
>
>
>
I believe rather crashed the system by overloading buffer time at a
tactrate soundcard isn't intended to be. So I would flag it as
dangerous.
What do you mean?