sbcl vs uvm

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

sbcl vs uvm

Manuel Giraud-4
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

Reply | Threaded
Open this post in threaded view
|

Re: sbcl vs uvm

Gregor Best-2
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

Reply | Threaded
Open this post in threaded view
|

Re: sbcl vs uvm

Manuel Giraud-4
Gregor Best <[hidden email]> 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