sbcl 2.2.7 fatal error encountered in SBCL pid 3703 tid 3724: Control stack exhausted while pseudo-atomic, fault: 0x7f96db01ffd0, PC: 0x5642307b294e

[Andrew Berkley]

This may not be an actual bug if it really is just out of stack space. But, if we run with a smaller (dynamic-space-size) this does not occur (this is with 96GB), so I'm not convinced this has much to do with stack space. So, I'm hoping someone familiar with what happens here can just declare this is a user problem not an sbcl problem.

#0 0x00007f96ec1fb23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7f96db55cb50, rem=rem@entry=0x7f96db55cb50) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
--Type <RET> for more, q to quit, c to continue without paging--
#1 0x00007f96ec200ec7 in __GI___nanosleep (requested_time=requested_time@entry=0x7f96db55cb50, remaining=remaining@entry=0x7f96db55cb50) at nanosleep.c:27
#2 0x00007f96ec200dfe in __sleep (seconds=0, seconds@entry=10) at ../sysdeps/posix/sleep.c:55
#3 0x00005642307967aa in configurable_lossage_handler () at interr.c:78
#4 0x000056423079682a in call_lossage_handler () at interr.c:116
#5 0x0000564230796a01 in lose (fmt=fmt@entry=0x5642307c8e38 "Control stack exhausted while pseudo-atomic, fault: %p, PC: %p") at interr.c:141
#6 0x0000564230799b4f in handle_guard_page_triggered (context=context@entry=0x7f96db55cd40, addr=addr@entry=0x7f96db01ffd0 "") at interrupt.c:1817
#7 0x00005642307aa58b in sigsegv_handler (signal=11, info=0x7f96db55ce70, context=0x7f96db55cd40) at linux-os.c:395
#8 0x00005642307973f5 in low_level_handle_now_handler (signal=11, info=0x7f96db55ce70, void_context=0x7f96db55cd40) at interrupt.c:1926
#9 <signal handler called>
#10 0x00005642307b294e in gc_find_freeish_pages (restart_page_ptr=restart_page_ptr@entry=0x7f96db020070, nbytes=nbytes@entry=1328, page_type=page_type@entry=3, gen=gen@entry=0 '\000') at gencgc.c:1486
#11 0x00005642307b30b6 in gc_alloc_new_region (nbytes=nbytes@entry=1328, page_type=page_type@entry=3, alloc_region=alloc_region@entry=0x7f96db5100f0, unlock=unlock@entry=1) at gencgc.c:1095
#12 0x00005642307b4d22 in lisp_alloc (thread=0x7f96db510080, page_type=3, nbytes=1328, region=0x7f96db5100f0, largep=0) at gencgc.c:5039
#13 alloc (nbytes=1328) at gencgc.c:5075
#14 0x0000000052a0041c in ?? ()
#15 0x000000000000028c in ?? ()
#16 0x0000000000000146 in ?? ()
#17 0x000000111f08e94f in ?? ()
#18 0x0000000000000530 in ?? ()
#19 0x000000111f08fdc0 in ?? ()
#20 0x000000000000051a in ?? ()
#21 0x000000111f08e94f in ?? ()
#22 0x000000111f08fdb8 in ?? ()
#23 0x0000000050100109 in ?? ()
#24 0x0000000050100109 in ?? ()
#25 0x0000000000200372 in ?? ()
#26 0x0000000000000000 in ?? ()

[Douglas Katzman (dougk)]

that definitely looks like stack overflow, which it can't handle while allocating.
Maybe try starting sbcl with "--control-stack-size N" where N is megabytes. The default is 2.
Also maybe try inserting
   extern void backtrace_from_fp(void *fp, int nframes, int start);
   backtrace_from_fp((void*)*os_context_fp_addr(context), 1000, 0);
into your configurable lossage handler. It should produce better output than gdb

[Andrew Berkley (ajberkley)]

Thank you! This is very probably our code problem and not an sbcl bug, so you can close this; sorry for taking up your time.