libera/#clasp - IRC Chatlog
Search
15:10:50
yitzi
Bike: adding `SortIncludes: false` fixed. Now format code for me clang-format minion!
15:11:47
mns
I haven't used gdb in a while, but Im familiar with it. I'll try and get a backtrace and add it to the issue. I'll need to get it installed on the freebsd system.
15:13:53
drmeister
mns: I'm guessing that when the multiprocessing code is being initialized it's doing something that freebsd doesn't like. We have a freebsd user who got this to work several months to a year ago (cracauer) but it hasn't been tested since then.
15:15:36
drmeister
It may be better for us to debug this because we are very familiar with the tools but you are very welcome to do it if you want to use this as an opportunity to get your hands dirty and better familiarize yourself with the tools.
15:16:19
drmeister
We are stretched pretty thin at the moment and cracauer is in Germany and tied up with other things. He is our freebsd expert.
15:17:17
mns
that's why I'm in it, to dirty my hands, and get back to doing things like this. :-) I'll see what I can do.
15:17:19
drmeister
The error message that you posted is pretty clearly the downstream effect of a downstream effect of a downstream effect of a problem in clasp that interacts poorly with freebsd.
15:18:23
drmeister
They don't directly illuminate what is going wrong. It looks like a crash when clasp is loading compiled code - when it's initializing itself. A low level, C-style, gdb backtrace may be more illuminating.
15:20:18
drmeister
The good news is that clasp is pretty debuggable at this low level. All stack frames in Clasp in bclasp are essentially C stack frames and gdb should be able to give us good information. Uh.... unless it doesn't. The initialization code involves a lot of compiled code that is loaded via the LLJIT and that may or may not register source information on freebsd.
15:20:21
mns
one of the impediments I have is that this is a headless freebsd server, so scrollin back to cut and paste is a little difficult with tmux/screen as compared to being in a terminal directly. Anyway, I'll see what I can do to contribute.
15:20:51
drmeister
The first thing we will learn is "do we get good backtraces". If we don't many of the function names you get will be hexadecimal addresses.
15:21:52
drmeister
Sort of - I didn't know which one you were more comfortable with. They both work.
15:22:50
drmeister
The procedure for interacting with the remote process is different in lldb than gdb.
15:43:57
yitzi
I haven't seen a successful build on debian:bookworm, so I am not judging by that. The current issue is whether the ubuntu:jammy makes it into dcando.
15:45:47
yitzi
I had to change the std::locale to get the build to work in the docker images, which breaks it if C.UTF8 isn't available. That PR would make getting the locale not needed.
16:54:47
drmeister
Bike: I tried to run under udb - it succeeded the one time I tried sadly. We should try again. If we had a recording we could mail down where it’s going wrong.
16:57:43
Bike
fffffairly quickly. sometimes it goes like half an hour and i think it might be hanging, but more often it dies within a few minutes
16:58:47
Bike
it goes into gethash, it calls cl:equal, and the dbg_safe_repr i put in to print a bad value segfaults
20:40:30
Bike
and when i say "the filenames" i mean the tmp ones, not the hardcoded references to build/
20:41:01
yitzi
I had it generate a script to call the serial analyzer versus calling the stuff in `run-XXXX` so I wouldn't walk on waf's feet.
20:42:46
yitzi
Since we don't have waf anymore, I think the correct answer to fix the various paths is to make proper entry point functions in the clasp-analyzer asdf system that accept compile-commands, log file locations, etc.
20:43:27
Bike
oh yeah and i did alter the koga script so it generates code to use the parallel analyzer instead
21:01:39
Bike
the hash table problem is specifically in memoized-probe-file in clang-tool, and that uses a global hash table
21:06:22
Bike
and both of those look like they lock correctly... maybe the read/write lock implementation itself is busted? man, i hope not
21:15:46
drmeister
Also, setf gethash and gethash don't just setf gethash and gethash - they rehash and that's where things get compilicated.
21:16:33
drmeister
The other thing would be to put a mutex in the code that accesses that hash table to test if that code is responsible.
21:17:29
Bike
i thought we did that by default, but i guess not, and the table in clang tool is NOT thread safe
21:39:13
Bike
there are a couple other non thread safe tables in clang-tool, but they look like they're not altered during use
23:44:16
drmeister
::notify Bike Good going - yes - I think we don't make them thread safe by default because that slows them down.
0:34:17
yitzi
I had to make the jupyter installer and snapshot scripts use the fasl output translation folder inside the build directory like the analyzer does. Now I can build cando in one build folder and clasp in a different one both in the same git repo.
0:46:24
Bike
if the problem is just contention i don't know if lock free tables would improve things much
0:46:24
Colleen
Bike: drmeister said 1 hour, 2 minutes ago: Good going - yes - I think we don't make them thread safe by default because that slows them down.
1:20:39
Bike
you still get contention if you just have multiple threads accessing memory with the same cache lines, right?
1:24:13
Bike
well, hopefully. it's still going. seems very slow, like slower than the serial version
1:31:04
Bike
i mean, this one is just a cache, and it's for different filenames, which might not be shared between threads either
2:19:43
Bike
memoized-probe-file is the one i just put the lock on, that i think could probably be thread local given that it's just a cache, but there are several more throughout clasp analyzer that i do not understand