Re: sbcl vs uvm
Gregor Best writes: > that looks like a stack space exhaustion. I've had something similar > while compiling > OCaml's merlin package. I solved it with the brutest of forces by adding > > :stacksize=infinity:\ Thank you for the hint but this does not work for sbcl (w/ thread) compilation. AFAIU, for each thread sbcl mmap a rather big area (about 5MB) as MAP_STACK. Don't know if it is usual? -- Manuel Giraud
Re: sbcl vs uvm
Hi Manuel, > [...] > trap [sbcl]46252/177072 type 6: sp 2f76e78b8 not inside 2f74f8000-2f76e8000 > [...] that looks like a stack space exhaustion. I've had something similar while compiling OCaml's merlin package. I solved it with the brutest of forces by adding :stacksize=infinity:\ to the limits for `staff` in my `/etc/login.conf`. Some more fine tuned stack size should do the trick just as well. -- Gregor
sbcl vs uvm
Hi, I used to build current sbcl (common lisp compiler) with threads support on -current amd64. For maybe 2/3 month, it does not compile anymore. On sbcl self test for threads, I get the following strange dmesg entry: trap [sbcl]46252/177072 type 6: sp 2f76e78b8 not inside 2f74f8000-2f76e8000 My question is: should I look for sbcl doing something nasty here or should I look for a bug in uvm? (I've cc'ed Josh because he has taken care of upstream patch after the MAP_STACK introduction) -- Manuel Giraud
