freenode/#clasp - IRC Chatlog
Search
13:19:44
Shinmera
I use a script to automatically pull all of my repositories to sync across machines. I suppose that could also be extended to sync with upstream if available.
16:00:49
Bike
trying to figure out this can't recover from FPE thing. really don't get it. the stack looks like it should have all the frames, but it doesn't i guess?
18:13:49
Bike
i hacked something to print all the rbp frames and the return frames, and it looks like it's there, but it's not
19:12:58
drmeister
Something that appears to have stopped working is backtraces when we suppress the repl.
19:44:45
drmeister
I'm moving core__btcl into C++ - I'm trying to eliminate depending on CL for backtraces.
19:50:10
Bike
cannot figure out the FPU error thing. ina signal handler with no SA_ONSTACK we ought to have the stack that was in place when the signal was received plus whatever signal functions, but we don't, except only maybe
20:34:18
drmeister
I'm not familiar enough with the issues Bike - or I'd weigh in. frgo might have some insight.
20:36:20
drmeister
I'll ask this - but it may be out of left field: What is necessary for the unix function backtrace(...) to function? When a signal handler is called and it pushes stuff onto the stack. Does that break backtrace?
20:38:38
drmeister
Yeah - but I wonder if lldb has special ways to handle things. gdb is supposed to be able to get backtraces even when you have -fomit-frame-pointer.
20:39:04
drmeister
I've seen backtraces truncated when you hit frames that were generated from code that was compiled with -fomit-frame-pointer.
20:41:32
frgo
Hm - I can get to github.com ... I wanted to share a link to a piece of code I always use for signal handling init...
20:41:42
drmeister
The frame-pointer linked list is what I always come back to in order to understand backtraces. If there is a frame-pointer in each frame - then you can chain back all the way through the stack.
20:46:15
Bike
ah, i see, the compiler just stores how much a function increments the stack pointer by
20:46:38
Bike
"So under gcc, all call stack problems seem to be solved – unless you trust the docs (!?)" pretty good environment here
20:50:12
Bike
the later parts about how you can reverse engineer this from the code are a bit wacky and i don't think they'd work with VLAs, which we do actually use
20:52:12
drmeister
Can we use a combination of digging the stackframe size out of the DWARF info and frame pointers?
20:55:44
kpoeck
Bike : don't know if this is still interesting, or you already know this one, from the currently free from acm library another article about ilog/talk https://dl.acm.org/doi/abs/10.1145/182409.156777
20:57:49
Bike
i also dug up the source code, that's right, but it was a restricted version and didn't have anything interesting i could find
20:58:09
Bike
drmeister: maybe? here's the thing though - the exception handling doesn't work. like, we make our Unwind exception, and throw it, and it's not caught. so even the C++ runtime can't recover the frame i guess
20:58:30
Bike
i tried turning off my libunwind frame check to see if it was just that failing, but no, the underlying exceptions aren't working either
21:35:55
drmeister
They are a bit ugly but lots of information. Function names, arguments, source info when available.