Hi Linas,
> Investigating the crash with good-old printf's in libguile/vm.c produces
> a vast ocean of prints ... that should have not been printed, and/or should
> have been actual errors, but somehow were not handled by scm_error.
> Using today's git pull of master, here's the diff containing a
Investigating the crash with good-old printf's in libguile/vm.c produces
a vast ocean of prints ... that should have not been printed, and/or should
have been actual errors, but somehow were not handled by scm_error.
Using today's git pull of master, here's the diff containing a printf:
--- a/libg
Exactly the same crash, same stack trace (slightly different line numbers),
with a fresh pull today:
commit 89e28df1c9069dcb65188fe7b3973c333d87d7e2
Author: Andy Wingo
Date: Thu Jun 20 14:02:05 2019 +0200
which is the current HEAD on master.
FWIW, 60-odd guile threads waiting here:
Below was for
guile (GNU Guile) 2.9.2.14-1fb399
--linas
On Sun, Jul 14, 2019 at 4:59 PM Linas Vepstas
wrote:
>
> So, here's my next installment on using guile-2.9.2. The first installment
> said that I'd piled up CPU-months of guile 2.9.2 experience without any
> crashes. Well, now, a different
So, here's my next installment on using guile-2.9.2. The first installment
said that I'd piled up CPU-months of guile 2.9.2 experience without any
crashes. Well, now, a different workload crashes in minutes. Below is a
highly simplified, edited gdb session -- it crashes because it unexpectedly
abo
Hi Mark,
Sorry for the late reply; my email client mananged to hide your email where
I won't see it. I need to fix this.
On Thu, Jun 6, 2019 at 11:28 PM Mark H Weaver wrote:
>
> You'll need to look at the stack frames on the Scheme stack. It can be
> done from GDB if necessary, but it might be
Mark H Weaver writes:
>> Two are stuck here:
>>
>> #0 __lll_lock_wait () at
>> ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
>> #1 0x7f343ca69bb5 in __GI___pthread_mutex_lock (
>> mutex=mutex@entry=0x7f343d4f0f40 )
>> at ../nptl/pthread_mutex_lock.c:80
>> #2 0x7f343d213
Hi Linas,
Linas Vepstas writes:
> I'm trying to understand how scm_jit_enter_mcode leads to
> scm_timed_lock_mutex ...
This simply means that 'lock-mutex' was called from Scheme, and
specifically from Scheme code that has been compiled to machine code by
our JIT compiler.
> I want to know who
I'm trying to understand how scm_jit_enter_mcode leads to
scm_timed_lock_mutex ... I want to know who is attempting to lock, and why
... and how to work around this...
Background: par-for-each works poorly for my app, I want to understand why.
Specifically, how par-for-each and n-par-for-each work
