Search
Thursday, 14th of January 2021, 17:06:29 UTC
18:05:23
karlosz
i guess its pretty easy to solve the problem of unnecessarily making new conses just by checking whether the car and cdr remain the same
18:09:06
karlosz
Bike: could you merge the bignum dumping pr? i have clasp side changes queued up for the ast munging
18:31:22
karlosz
an interesting not about the ast interpreter - we don't actually need a linked list of frames, since the environment has already disappeared by the time we converted to an ast, so just a flat mapping will do
18:44:49
Bike
build seems to segfault now. hm.
18:45:18
karlosz
after merging the bignum?
18:45:35
karlosz
hm, i ran the ansi-tests
18:45:54
Bike
also, not a segfault, sigbus.
18:46:01
karlosz
like just a normal build, or with cando etc?
18:46:01
Bike
i'll make sure it worked before the merge
18:46:29
karlosz
i don't think i've ever seen a sigbus from clasp before
18:46:47
Bike
the actual error is UNDEFINED-FUNCTION (BUS-ERROR)
18:47:00
Bike
maybe it's the "Undefined instruction" error from infinite recursion? I dunno
18:47:20
karlosz
well the buildbot just finished building asdf
18:49:46
karlosz
where in the build are you getting the error?
18:50:12
karlosz
did you distclean and everything?
18:50:22
karlosz
buildbot is currently in the middle of building quicklisp
18:50:59
karlosz
you're building on bigmac right? that's pretty weird
19:09:53
Bike
works before the merge. very odd.
19:20:26
karlosz
yeah, given that the buildbot just succeeded on it too
19:20:36
karlosz
well a sigbus means something nefarious
20:36:24
kpoeck
i also get datum: UNDEFINED-FUNCTION (:NAME BUS-ERROR)
20:36:55
kpoeck
23: 25 iclasp-boehm 0x0000000105ba4178 _ZL7startupiPPcRbRiS2_ + 1304
20:42:36
kpoeck
i even have a backtrace in lldb
20:44:25
kpoeck
core::ltvc_read_bignum is in the backtrace
20:46:18
kpoeck
here all info: https://gist.github.com/kpoeck/e077bfac7c8685170fc76053cb02e9d7
21:13:44
karlosz
kpoeck: thanks a lot, i can look at that
21:13:51
karlosz
that's weird that it only happens sometimes
21:13:58
karlosz
or for certain people i guess
21:14:04
karlosz
clasp has been building fine on bigmac for me
21:14:26
kpoeck
I am still inlldb, if you need info from any frame?
21:15:33
karlosz
i think i've seen this error before
21:15:45
karlosz
but it went away, after what i assumed was just wiping out all the fasls
21:15:50
karlosz
maybe its more than that
21:16:32
karlosz
it's problematic that i can't reproduce though
21:17:57
karlosz
kpoeck: can you get the info around the frames that have to do with ltvc_read_bignum?
21:27:02
kpoeck
i added this to the gist
21:31:37
karlosz
i don't understand why it looks like we're in a lisp frame
21:32:57
karlosz
oh, i guess it must be because early in the bootstrap the bus error handler hasn't been defined yet
21:35:32
karlosz
it's dying in the allocator
21:35:51
karlosz
which means that at most the length would be corrupted
21:36:57
karlosz
also for whatever reason frame 47 doesn't show the size variable, which is extremely unhelpful
21:42:04
karlosz
oh here we go: (int64_t) length = -9223372036854775808
21:42:51
karlosz
that would certainly give a bus error
21:43:27
karlosz
which file is it loading when this error happens?
21:43:36
karlosz
is it predlib or some other file?
21:44:12
karlosz
Bike: if i go into your clasp directory and build will i be able to get the same error?
21:44:40
Bike
it seems pretty reproducible, sure. let me put it back at the commit... there you go
21:45:09
karlosz
still bizarre that it works for me but not for you
21:45:30
Bike
yeah, dunno what's going on there.
21:45:37
karlosz
i guess i should double check our wscripts are similar
21:46:18
karlosz
are there ny other build configuration things that might give us different build artifacts on the same machine?
21:48:22
karlosz
be back in about an hour to look at this more closely
21:51:16
kpoeck
it loads /Users/karstenpoeck/lisp/compiler/clasp-karsten/build/boehm/fasl/aclasp-boehm-image.fasp
22:47:33
Bike
parsing sort of working. (specifier-ctype '(or fixnum (function (t &rest t) cons))) => #<DISJUNCTION (OR (INTEGER bla bla) (FUNCTION (T &REST T) CONS))>
22:47:49
Bike
four hundred lines of code, and i still need to do string, and that doesn't count deftype expansion. yeesh.
23:27:44
kpoeck
with __attribute__((optnone)) CL_DEFUN size_t core__ltvc_write_bignum and
23:28:03
kpoeck
__attribute__((optnone)) T_O* ltvc_read_bignum
23:31:21
Bike
oh, so it's doing something nonconforming
23:32:26
Bike
i suppose the fact it treats things that can be negative as size_t might cause weird problems
23:33:41
Bike
ltvc_read_bignum uses compact_read_size_t to read the bignum length. compact_read_size_t returns a size_t, which is never going to be negative. might be an issue.
23:35:36
Bike
(specifier-ctype '(or (rational 1 5) (rational 6 10))) => #<DISJUNCTION (OR (INTEGER 1 10) (AND (NOT INTEGER) (RATIONAL 1 5)) (AND (NOT INTEGER) (RATIONAL 6 10)))>, that's kind of cool
23:36:15
karlosz
are you normalizing to CNF or something?
23:36:43
Bike
it's just that it treats (rational x y) as (or (integer x y) (ratio x y)), basically
23:37:11
Bike
(and (not integer) (rational x y)) is how it displays (ratio x y), since (ratio x y) isn't a real type specifier
23:37:34
karlosz
i forget how sbcl handles OR and AND types, but we probably want to normalize it to cnf or dnf in any case
23:38:07
Bike
i was thinking dnf, but i haven't really put any effort in to that yet
23:38:17
Bike
and so i'm not totally sure the simplifier always halts
23:39:07
karlosz
i think sbcl's ctype functions do the normalizing as part of their operations
23:39:18
karlosz
so it's hard to construct an unsimplified ctype
23:39:22
Bike
yeah, they do. i've been referring to them kind of a lot.
1:49:08
karlosz
Bike: i was able to build clasp in your directory after a 1 line change
1:49:15
karlosz
if you odo git diff you'll see what i did
1:49:23
karlosz
hopefully that was the problem?
1:49:44
Bike
oh, yeah, that's definitely a problem
1:49:55
Bike
using compact_read_size_t to get a negative number still kind of concerns me, but oh well
1:50:34
karlosz
i find the signed magnitude thing kinda bizarre still, but i guess that's what they do
1:50:47
Bike
it's pretty usual for bignum implementations, as far as i can tell
1:50:59
Bike
makes the bitwise operations a pain in the ass though
1:54:16
Bike
i think it's that with two's complement multiplication gets kind of stupid
2:00:43
Bike
karlosz: are you still building in my directory?
2:00:54
karlosz
i think that was the fix
2:01:12
Bike
it's giving me some permission error. guess i just need to axe some stuff
2:01:31
karlosz
yeah i used sudo to build in your directory
2:01:35
karlosz
because i don't have permissions
2:01:52
Bike
deleting the build directory was enough
2:03:08
karlosz
i guess a negative vla would be really bad, and that does tmatch the error given
2:03:29
karlosz
i don't know enoguh about C++, but i think in C its okay to go back and forth between unisgned and signed integers
2:03:33
Bike
yeah, trying to allocate nine quintillion bytes or whatever might cause a sigbus
2:04:15
Bike
every so often i learn the C conversion rules, and then i forget them because they're weird and boring
2:04:27
Bike
and C++ has shit like "glvalues" so that's just a no-go
2:06:48
Bike
let's see. "if the target type can represent the value, the value is unchanged. [...] otherwise, if the target type is signed, the behavior is implementation-defined"
2:07:20
Bike
maybe someday we can run some strict llvm pass that'll print out six thousand warnings
2:30:33
drmeister
Did you get it to work? Another issue with negative bignums?
2:36:43
drmeister
I've managed to get boehmprecise to work with precise Cons_O cells whoho
2:37:06
drmeister
It's still crashing when I try to increase the number of objects that are treated precisely.
2:37:28
drmeister
I'm beefing up my python/udb debugging tool and using that to debug the problem.
2:37:40
drmeister
Objects don't move - that makes life a little easier.
2:43:06
drmeister
I'm going to make a pandemic TV show recommendation...
2:43:34
drmeister
"Ghosts" on HBO mx
2:43:36
drmeister
https://www.imdb.com/title/tt8594324/
2:43:43
drmeister
It's pretty funny
3:28:03
drmeister
karlosz: Was the bignum literal compilation apparent in the flamegraph?
3:49:57
karlosz
drmeister: yes, it was prominent while compiling cryptographic lbiraries like ironclad and compression/uncompression libraries with lots of type declarations
4:02:59
beach
Good morning everyone!
4:09:58
drmeister
karlosz: Thank you.
Friday, 15th of January 2021, 5:06:29 UTC