Search
Thursday, 15th of February 2018, 8:06:15 UTC
14:01:04
flip214
when in GDB in lower_thread_control_stack_guard_page(), how can I get the lisp stack to find the offending function?
14:02:16
flip214
stassats: no, the problem occurs with vlime (a vim plugin using swank),
14:02:27
flip214
and so the stacktrace goes to a then-broken setup
14:05:47
flip214
http://www.sbcl.org/manual/: "Project web is currently offline pending the final migration of its data to our new datacenter."
14:08:31
flip214
stassats: no, --lose-o-c doesn't help me... still only have "INFO: Control stack guard page unprotected"
14:09:06
stassats
then you're putting it in the wrong place
14:10:26
stassats
maybe it's not a corruption then
14:12:25
stassats
make it lose by recompiling the runtime
14:13:18
flip214
can I get information from the siginfo_t?
14:15:52
flip214
(gdb) p lose_on_corruption_p
14:15:57
flip214
what do I need to change before recompiling?
14:16:49
flip214
Either I simply don't understand you (because I don't know enough SBCL internals?), or you're just kidding
14:17:38
flip214
ah, you mean I should insert that line in the l_t_c_s_g_p()?
14:18:04
flip214
lower_thread_control_stack_guard_page
14:18:42
flip214
well, from GDB I just did "call lose("aa")"
14:19:06
flip214
too bad that the sbcl manual isn't available right now
14:19:38
flip214
the rendered one on the internet
14:19:44
flip214
I'm reading the texinfo sources now
14:20:29
stassats
not sure what in the manual can help with stack exhaustion and a broken debugger
14:21:13
flip214
I'd be interested how to use LDB, for example
14:23:11
flip214
tells me 0: Foreign function, 1: Foreign function
14:23:14
stassats
i don't think there's anything in the manual anyhow
14:23:57
flip214
that's what my search through the manual page and the texinfo turned up, yes.
14:25:05
stassats
flip214: do fake_foreign_function_call(context); lose("abc"); before the call to lower_thread_control_stack_guard_page
14:26:23
stassats
are building with :sb-dynamic-core? with that you can rebuild just the runtime
14:30:05
flip214
got a backtrace, thanks a lot!
14:38:22
flip214
yeah, two of the LABELS there call themselves...
14:39:07
flip214
Is there some simple optimization setting to get (only?) tail-call optimization within that function, without sacrifying SAFETY too much?
14:40:01
stassats
there's no optimization to disable tail calls
14:40:34
stassats
other than debug 3, which doesn't disable them, but just wraps the forms into something making them non-tail
14:41:07
flip214
The elimination of tail-recursive frames can be prevented by disabling
14:41:07
flip214
tail-recursion optimization, which happens when the @code{debug}
14:41:07
flip214
optimization quality is greater than @code{2}.
14:41:07
flip214
@xref{Debugger Policy Control}.
14:41:17
flip214
hmmm, but nothing to enable them
14:41:53
stassats
you can't control them at all, as i said
14:42:01
stassats
besides making the calls non-tail
14:42:48
flip214
for a (LABELS ((foo (...) ... (foo)))
14:43:07
flip214
what would a RETURN-FROM foo do? Only return from the innermost call, right?
14:44:29
flip214
but with a tail-recursive function, that means that _all_ frames are quit
14:46:29
flip214
so a simple LOOP instead of self-calling should be good enough
14:52:13
stassats
i'll make --lose-on-corruption lose on the first stack guard page
14:52:54
stassats
the fine manual even lists stack exhaustion for --lose-on-corruption
16:21:52
flip214
how can I tell the SBCL build system to retain debug information (on the C sources)?
16:22:59
flip214
would setting CFLAGS and LDFLAGS work across all the compilation runs?
Thursday, 15th of February 2018, 20:06:15 UTC