Hi Kapten! Looks like a bug in libgc somehow. Did you ever trace this down?
Andy On Tue 08 Apr 2014 16:45, Kapten Anto <evul.tr...@gmail.com> writes: > On my system its quite simple to reproduce, start guile, type ,q > enter, then start it again and it crashes. In between runs Ive > verified it does not show up in the process list, ps aux|grep guile. > > ~ $ guile > GNU Guile 2.0.11 > Copyright (C) 1995-2014 Free Software Foundation, Inc. > > Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. > This program is free software, and you are welcome to redistribute it > under certain conditions; type `,show c' for details. > > Enter `,help' for help. > scheme@(guile-user)> ,q > > ~ $ guile > guile: ../nptl/pthread_mutex_lock.c:80: __pthread_mutex_cond_lock: > Assertion `mutex->__data.__owner == 0' failed. > Aborted (core dumped) > > ~ $ guile > GNU Guile 2.0.11 > Copyright (C) 1995-2014 Free Software Foundation, Inc. > > But doesnt happen every time. Seems like every other or every third > time. > > Here is a backtrace from gdb > > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > Core was generated by `guile'. > Program terminated with signal SIGABRT, Aborted. > #0 0x00007feab193b389 in raise () from /usr/lib/libc.so.6 > (gdb) bt > #0 0x00007feab193b389 in raise () from /usr/lib/libc.so.6 > #1 0x00007feab193c788 in abort () from /usr/lib/libc.so.6 > #2 0x00007feab19344a6 in __assert_fail_base () from /usr/lib/libc.so.6 > #3 0x00007feab1934552 in __assert_fail () from /usr/lib/libc.so.6 > #4 0x00007feab1cbf3a4 in __pthread_mutex_cond_lock () from > /usr/lib/libpthread.so.0 > #5 0x00007feab1cba0df in pthread_cond_wait@@GLIBC_2.3.2 () from > /usr/lib/libpthread.so.0 > #6 0x00007feab16b8897 in ?? () from /usr/lib/libgc.so.1 > #7 0x00007feab16aecd5 in ?? () from /usr/lib/libgc.so.1 > #8 0x00007feab16aee9b in ?? () from /usr/lib/libgc.so.1 > #9 0x00007feab16afcbd in ?? () from /usr/lib/libgc.so.1 > #10 0x00007feab16a63bd in ?? () from /usr/lib/libgc.so.1 > #11 0x00007feab16a6daa in ?? () from /usr/lib/libgc.so.1 > #12 0x00007feab16a6fd6 in ?? () from /usr/lib/libgc.so.1 > #13 0x00007feab16a709d in GC_gcollect () from /usr/lib/libgc.so.1 > #14 0x00007feab1f3c704 in scm_realloc () from > /usr/lib/libguile-2.0.so.22 > #15 0x00007feab1f334de in scm_c_register_extension () from > /usr/lib/libguile-2.0.so.22 > #16 0x00007feab1f23d93 in ?? () from /usr/lib/libguile-2.0.so.22 > #17 0x00007feab1f4c21f in ?? () from /usr/lib/libguile-2.0.so.22 > #18 0x00007feab1f9ff00 in ?? () from /usr/lib/libguile-2.0.so.22 > #19 0x00007feab1f9ff39 in ?? () from /usr/lib/libguile-2.0.so.22 > #20 0x00007feab16b1d42 in GC_call_with_stack_base () from > /usr/lib/libgc.so.1 > #21 0x00007feab1fa0328 in scm_with_guile () from > /usr/lib/libguile-2.0.so.22 > #22 0x00007feab1f4c195 in scm_boot_guile () from > /usr/lib/libguile-2.0.so.22 > #23 0x0000000000400c54 in ?? () > #24 0x00007feab1927b05 in __libc_start_main () from /usr/lib/libc.so.6 > #25 0x0000000000400cc7 in ?? () > (gdb) > > # uname -a > Linux precizija 3.13.7-1-ARCH #1 SMP PREEMPT Mon Mar 24 20:06:08 CET > 2014 x86_64 GNU/Linux > > Any other information needed? How can I dig more into why this is > happening? > > Regards