Hi Pierre-François, Sorry for the delay of my answer. I have traversed a really a busy period...
> Did anyone from Bigloo had the time to look at this issue ? > > Thanks, > Pierre-Francois > > From: Ollagnon, Pierre-Francois > Sent: Wednesday, August 12, 2020 4:00 PM > To: big...@sophia.inria.fr > Subject: Bug in GC (and maybe more) using pthread and (repl) > > Hello, > > It's been a while that I have some random issue. > My understanding is that the methodolgy used to abort something in the (repl) > using Ctrl-C is not "thread safe" > > I have seen that when we launch functions making a lot of allocation, > sometime when we hit Ctrl^C the repl get stuck and every thing is blocked. > Using GDB we can see that a thread is launching a GC_malloc_kind which is > stuck in a __lll_lock_wait. > > This thread is deadlock with himself because he want to lock a mutex that is > already locked by himself. > > I'm not realy sure if it is the GC that should handle this or Bigloo. > But in my case, it is not the only issue: sometime when hitting Ctrl-C my > tool silently quit, or quit with something like: > > ^C*** ERROR:unwind-until!, #<pthread:batch> > exit out of thread dynamic scope -- #unspecified > > So I feel that it is more coming from Bigloo ... > (note that the "batch" pthread is not the one who run the (repl) ) > > > ======================================================= > .scm testcase: > ======================================================= > (module test-main > (main main) > (library pthread) > (export make-some-allocation > make-pthread-allocation) > (eval (export-all))) > > (define (make-pthread-allocation) > (let ((th (instantiate::pthread (body (lambda () > (make-some-allocation)))))) > (thread-start-joinable! th))) > > (define (make-some-allocation) > (let ((res '())) > (for-each > (lambda (x) > (set! res (cons (format "Number is: ~a" x) res))) > (iota 1000000)) > res)) > > (define (main argv) > (repl)) > ======================================================= > > Compilation with bigloo -cg > > > Usage: > Just launch several times (make-some-allocation) and > (make-pthread-allocation) and do some CTRL^C in between. > At a moment, the command line "1:=> " will not be printed back I'm not able to reproduce that problem. Unfortunately it does not mean that the problem is gone (the charm of multi-threaded programs). However, we can have a reasonable hope that the problem has been naturally fixed by the new library naming convention that avoids many confusion between multi-threaded and single-threaded links. Would you have time to give 4.4a (bigloo-unstable) a try and let us know if the problem is fixed for you too or not? Thanks in advance. -- Manuel ps: If that's possible for you, I suggest that we pursue this discussion on github. It's easier to keep track of all issues when all the discussions take place at the same place.
