Subject: Re: bug#17223: guile crash, signal 6, guile: ../nptl/pthread_mutex_lock.c:80

From: Andy Wingo <[email-masked]>
Date: Tue, 28 Feb 2017 15:10:25 +0100

Hi,

I am closing this bug as we have no more info.  Happy hacking with Guile
:)

Andy

On Tue 21 Jun 2016 15:09, Andy Wingo <[email-masked]> writes:

> 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 <[email-masked]> 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