libera/#clasp - IRC Chatlog
Search
14:47:12
Bike
i... think it might be crashing while generating object layouts for the debugger. is that possible?
14:47:52
Bike
it prints the "Generating clasp object layouts" message and then the next line is unhandled std::exception
14:49:48
yitzi
I am getting a pile of "warning: Section .debug_aranges in <in-memory> has duplicate debug_info_offset 0x0, ignoring .debug_aranges."
14:54:55
Bike
okay, yeah. i can set up a build that works if i do it normally, but if i run it under bin/debug it crashes. what the hell.
14:57:20
Bike
and e.what() is "invalid type specifier", and i don't know where the heck that's coming from
15:25:00
drmeister
REgarding: warning: Section .debug_aranges in <in-memory> has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
15:26:17
drmeister
Bike: I switched fmt to use fprintf(ostream...) probably within a few hours of when the fmt people removed support for fprintf(ostream...)
15:27:38
drmeister
That's all - all I asked was that a C++ library (fmt) support a completely normal C++ feature (ostreams)
15:29:27
yitzi
I fixed it here https://github.com/clasp-developers/clasp/commit/aaeedd079551ff27fa02aa508067326c4fd81761
15:31:14
Bike
hrm, i do have this change but i'm still seeing the problem. you can run clasp under bin/debug?
15:31:59
yitzi
And yes, it supports ostream. Just not on fmt::fprintf...we need to switch to fmt::print etc.
16:25:47
Bike
"There was an unhandled std::exception in process [pid: 3489832] e.what()=[invalid type specifier] - do something about it.
16:29:02
drmeister
And you are trying to connect with udb -p <pid> - what does the backtrace look like?
16:30:00
Bike
i tried just running it under udb, and the baacktrace i got was useless because it was in the middle of exiting, and reversing didn't really improve the situation somehow.
16:33:24
drmeister
I changed the way the python debug info was generated like 24 hours ago. In that 24 hours the fmt library appears to have removed support for the thing I used. Now we need to switch it to something else.
16:37:49
drmeister
The clang community still hasn't finished support for std::format - if they did we wouldn't be in this mess.
16:46:10
drmeister
I was trying to avoid changing every printf style format specifier to {} because that's a massive pain in the butt.
16:47:02
yitzi
The error is coming from my push. But without my push I can't compile on Arch or Mac.
16:47:57
yitzi
Here is the commit https://github.com/clasp-developers/clasp/commit/aaeedd079551ff27fa02aa508067326c4fd81761
17:01:27
drmeister
I would have probably tried to squeeze another development cycle out of the %x style.
17:03:11
drmeister
I had it under control of CLASP_DEBUGGER_SUPPORT because it used to generate a file in /tmp/
17:03:59
drmeister
It would allow us to connect the debugger to any running clasp/cando and get good lisp debug info.
17:04:33
drmeister
I'm going to do that. It would be nice to REMOVE an environment variable for once.
17:09:27
drmeister
Ah - it won'd remove an environment variable because I want it to also write the pid to /tmp/pid-<user> for now.
17:26:21
Bike
should i merge in the changes where i remvoed the interpreter? into vm, i mean. it means you need that implicit compile option in configure_clasp.
17:45:36
drmeister
Jeeze - I've been trying to set an environment variable AMBERHOME through jupyterhub for an hour. Then I find this... https://github.com/jupyterhub/the-littlest-jupyterhub/issues/308
17:46:15
drmeister
The guy tries 8 different ways to set an environment variable, some of which are documented as being THE way to set the environment variable and it not work.
18:21:37
Bike
the nested error depth shit i'm hitting is because seomthing's doing As<Vaslist_sp> and not getting a vaslist... interesting.
18:24:21
Bike
wow, and the underlying error is unknown opcode 80. something really screwy is happening.
18:24:42
Bike
but why would a wrapper not actually be passing a vaslist. surely &va-rest is working by now
18:39:15
Bike
this is all from turning off the compiler in clos/combin, by the way, rather than a vm thing directly
19:19:15
yitzi
I think I am getting an error from inside makePathname when it tries to call the test function of assoc. https://plaster.tymoon.eu/view/3440
19:23:24
yitzi
I have a branch that dumps the alists of the translation tables and used hash tables instead. Maybe I should try that.
19:25:09
Bike
lcc_nargs = 140136474256608, lcc_args = 0x0<__clasp_gcroots_in_module_trampoline>. wow, what the fuck did i do to cause that
19:37:38
drmeister
Bike: That's pretty normal - that's the system's way of saying something is effed up.
19:38:04
Bike
i really wish udb had something to automatically fill in the optimized out variables based on the history
19:38:20
drmeister
If you are looking at a frame higher up the stack than the frame that the error occurred then the numbers may be crap.
19:38:47
drmeister
I find though that if I back up into the frame with udb then if the variables haven't been optimized away - then they are good.
19:39:11
drmeister
If you step onto an instruction and check the registers - they are absolutely true.
19:40:12
drmeister
With udb right now you can step through machine instructions and variables will become available and disappear instruction by instruction. It's remarkable.
19:41:46
drmeister
Yeah - I haven't figured that out yet. But I have seen many cases where values that the backtrace displays are weird and they change as I reverse back and get closer to that frame.
19:42:21
Bike
ok. whatever. i do have what is probably the original error, or at least something i'm pretty sure is real, the unknown bytecode
19:43:59
drmeister
You can put break points on specific instructions by saying: `break *<instruction-address>`
19:44:59
Bike
it's got like fifteen thousand frames of bytecode_vm so it's probably going through almost all instructions
19:45:10
drmeister
My experience is the machine code and registers you can take to the bank. The source info that udb layers on top of it can be wrong sometimes.
19:45:56
drmeister
I had a breakthrough with debugging the VM a couple of days ago - it's what let me find the _longjmp thing that was messing with framepointers.
19:46:31
drmeister
I print debugging output (carefully) and then write a CL program to process it and find where problems occur.
19:47:23
drmeister
It was very helpful debugging the push_frame and pop_frame - The CL program loaded all the pushes and pops and identified when a pop occurred that didn't match a push.
19:53:45
Bike
ok, so backquote_append is also a C++ function with a wrapper with &va-rest. a pattern is forming.
19:57:47
Bike
and yet i'm only seeing problems with this generic function thing changed, so what the hell.
20:10:47
Bike
i had it print out everything it maybe-compiles, and it looks like it actually crashes halfway through printing one. well that's pretty frickin suspicious.
20:15:08
Bike
although actually that could just be a recursion thing, so i guess i should guard against that
20:39:04
Bike
i suspect that the vm goes really pear-shaped on infinite recursion, but i haven't yet caught it in the act. might need va-rest or something...
20:43:10
drmeister
I didn't get the page guard right on the VM - so the stack overflows without telling you it is overflowing.
20:44:03
drmeister
Edit clasp/include/clasp/core/configure_clasp.h down at the bottom you turn on DEBUG_VIRTUAL_MACHINE and it will catch overflows.
21:31:37
Bike
ok, so avoiding bclasp/cclasp in clos is going to boil down to the sort of stuff we were already doing to make discriminate stop doing weird internals stuff as much as possible, looks like
21:40:30
Bike
although... actually, there's probably not much point in bytecompiling the reinitializers and other static gf things... hrm...
2:42:42
Bike
and i'm not sure doing the static-gfs optimizations is even worthwhile if we just bytecompile stuff (it might be though)