Why SIGABRT

Joël Krähemann weedlight@gmail.com
Mon Aug 18 23:48:00 GMT 2014


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?




More information about the Libc-help mailing list