freenode/#clasp - IRC Chatlog
Search
4:39:36
Kevslinger
Xeus (what we were calling Xenon or Xeon or whatever today) seems to be a new, lightweight IpyKernel. They have a python and C++ implementation currently
4:42:17
Kevslinger
Here's the base: https://github.com/QuantStack/xeus and then there's also a C++: https://github.com/QuantStack/xeus-cling
13:39:36
drmeister
This is the relevant part of the backtrace - generated with (core:safe-backtrace)
13:40:38
drmeister
This is something I thought we could never do - segfault - catch it - unwind - do it again.
13:41:26
drmeister
Dereferencing NULL is a pretty common way that I segfault because in C++ I sometimes use variables that I haven't set up yet.
13:45:25
Bike
i might be able to have it find the address that caused the problem as well, if that would help
13:47:41
drmeister
This is going to help tremendously with debugging once other people start hitting these.
13:48:15
drmeister
I should use (core:safe-backtrace) when we get a SEGMENTATION-VIOLATION in jupyter notebooks - then it would show the C++ functions as well.
13:51:10
davidlovemore
In one ARM JIT I worked on, we used to regularly BL (Branch and link) to 0 conditionally to generate an error as part of debugging. Brings back memories.
13:54:16
selwyn
drmeister: do your collaborators prefer to develop with jupyter notebooks over emacs?
13:54:43
davidlovemore
The address should be on the stack. You can definitely get at the registers after a fault. The MPS code does this. The return address should be in [rsp].
13:55:26
drmeister
selwyn: They will - yes. I also prefer it because I use it to interactively debug complex things like geometry optimization.
13:55:45
drmeister
selwyn: We connect a slime session into the jupyter notebook - so we get the best of both worlds.
13:56:07
Bike
well i was wondering if we could get the address in memory that was improperly accessed, like 0 in this case
14:03:10
Bike
"For some implementations, the value of si_addr may be inaccurate." good old standards.
14:05:41
drmeister
By implementation they mean operating system - right? Since we only support Linux, FreeBSD and macOS - maybe we will get lucky?
14:13:53
drmeister
I should be able to do this - right? (make-array 2 :element-type 'single-float :initial-contents #( 1.0d0 2.0d0))
14:14:20
drmeister
Initialize a single-float specialized vector with a simple vector of double-floats?
14:15:46
drmeister
No -apparently not. "Each leaf of the nested structure must be of the type given by element-type. "
14:22:39
drmeister
The compiler warnings we are getting now in slime are fantastic! Programming is very zippy.
14:28:56
davidlovemore
Bike: si_addr seems to work on intel linux. You can get at the regs via the u_context_t structure passed to the third argument of the sigaction callback.
14:30:26
Bike
yeah, i've looked at the context a bit. i'm not sure we need to do anything with them in the lisp debugger, though they might help with the float traps debacle
14:34:45
Bike
when we do floating point arithmetic in lisp we'd prefer to signal an error rather than get NaNs like the default. i tried to set it up (by setting the FPU to trap, which ends up as a SIGFPE) but i couldn't get it working consistently
14:36:19
davidlovemore
My guess is something somewhere is messing with the FPU configuration which you can kind of do on intel, so the behaviour might depend on what libraries might have been initialized or called recently.
14:37:18
Bike
ugh. that sounds even worse than i was dealing with. there's no standard way to access the float traps, was my first problem, so i was using intel intrinsics
14:37:34
Bike
and then i found that upon entrance to a signal handler the fpu register is reset, for some reason
14:38:55
davidlovemore
Yes, that makes sense. the fpu is put into a standardized state for the traps but as you indicate, looking at the registers might help you detect what state it was in when the trap happenned.
14:39:26
Bike
that wasn't my only problem, unfortunately, and i want to deal with specifics of mcontext and stuff as little as possible
14:42:45
Bike
plus i dug into the IEEE 754 stndard a bit and there are language independent operations for setting trap states, as far as i understood, so it's annoying that C doesn't provide anything
14:45:21
davidlovemore
But from an implementation point of view isn't it better to do a whole load of floating point and then if x!=x (true on NaN) repeat mre carefully. Traps are slow. Conditional branches that are rarely taken are pretty much instant.
14:47:20
Bike
i don't know what's faster. but we don't have an effective way to automatically group floating point computations together, and doing a check after every operation would probably be slow
14:50:38
Bike
Oh, yes, for the programmer I was intending to allow dynamic control of the fpu traps, and it wouldn't be hard to put specified checking on top of that
14:50:56
Bike
but our language standard specifies errors being signaled, so that's what i wanted to start with