Search
Monday, 17th of December 2018, 17:49:53 UTC
18:16:33
stassats
|3b|: i pushed without testing and waited for the CI to fail
18:18:55
phoe
does the CI push the builds it makes somewhere?
18:19:21
phoe
would be handy if it kept the last 10 binaries or something
18:19:32
stassats
you might be able to download the workspace
18:21:27
scymtym
phoe: can't afford that storage-wise
18:21:45
|3b|
stassats: didn't -FPIC stuff in tests get fixed for arm64 already?
18:21:47
phoe
how much does a single built SBCL weigh?
18:21:58
stassats
|3b|: what fpic stuff?
18:22:19
|3b|
not passing -fpic it when building foreign libs for test suite
18:22:47
phoe
10 builds per platform * 3 platforms * 20MB per build = 600 MB of storage
18:22:55
stassats
i'm drawing a blank there
18:23:15
scymtym
phoe: for linux, it archives the three most recent builds. e.g. https://ci.cor-lab.org/view/sbcl/job/sbcl-master/featureset=default,label=ubuntu_trusty_64bit/
18:23:38
phoe
scymtym: I see! I'm looking for Windows builds./
18:24:06
|3b|
tests/run-compiler.sh doesn't have a case for Linux-ARM64, so doesn't pass -fPIC when compiling things
18:24:11
stassats
if i'm ever going to get around using Azure for testing, i'm sure microsoft can afford that
18:24:19
scymtym
phoe: you can try the "all in one zip file" at the bottom of https://ci.cor-lab.org/view/sbcl/job/sbcl-master-windows/label=Windows_7_64bit/ws/ *when is it not currently building*
18:24:49
scymtym
stassats: yes, longer-term a different solution would be good
18:24:52
|3b|
kill-non-lisp-thread.impure.lisp fails due to "relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `wait_a_bit' which may bind externally can not be used when making a shared object; recompile with -fPIC
18:25:11
|3b|
ACTION thought we fixed that last time i was running into problems with tests on arm
18:25:13
scymtym
we could even try travis for the platforms they support
18:25:26
stassats
if it fails, then it hasn't been fixed
18:25:50
stassats
you might have had it fixed locally
18:26:34
stassats
well, that case is silly
18:27:23
|3b|
does seem like it should be a blacklist rather than whitelist, if some platform doesn't need it
18:28:16
|3b|
i don't see linux-x86 in the list
18:31:51
|3b|
though might not hurt on some/all of those
18:34:25
|3b|
tests run now on arm64 though, thanks :)
0:24:25
stassats
joy, trying to fix one problem with run-program i discover another
0:48:39
stassats
somehow with-pinned-objects is not pinning hard enough
1:00:43
|3b|
ACTION wonders about that (pinning enough), though assumed it was just my code4 being broken :)
1:01:35
|3b|
actually, maybe i decided it was just syscalls being interrupted that was breaking things for me instead
1:03:46
stassats
eintr would explain this, but it gives me EFAULT
1:05:44
stassats
and the problem disappears when i use a static vector
1:08:27
stassats
it says EFAULT it doesn't say it's been moved
1:09:48
stassats
disabled page protection for GCing and it's working again
1:09:59
|3b|
ah, that would make sense too
1:11:10
stassats
that means you can never pass a lisp vector to the kernel
1:11:45
|3b|
but at least knowing that is better than not
1:12:23
stassats
so, need with-pinned and with-no-protection
1:13:24
stassats
suppose with-pinned implies no protection
1:24:17
stassats
protect_page_p does imply that, but not update_page_write_prot
1:27:44
stassats
now i can actually test my original problem
1:38:53
stassats
and remove without-gcing from run-program
1:39:46
stassats
run-program is abysmal
1:47:33
stassats
|3b|: you could try your syscalls again
1:49:13
|3b|
ACTION will try again if i ever get a working configuration :/
1:50:05
|3b|
(and was reasonably rare problem anyway, program doesn't GC too much)
1:50:17
stassats
yeah, i was gcing in a loop
1:50:36
stassats
but still, a rare problem is even worse
1:50:55
|3b|
yeah, will try to stress it when i have things running again
1:51:39
|3b|
though attempted stress changes things a lot since it is doing sort-of-realtime stuff
1:51:48
stassats
or you don't test it and hope i just fixed it
1:52:00
stassats
cause otherwise i'll have to fix something else again
1:52:24
stassats
i don't know about a bug => there's no bug
2:34:22
stassats
(loop (gc)) exhausting the heap is getting old
2:42:29
stassats
why can't that SB-KERNEL::*GC-EPOCH* be gced
2:54:09
stassats
for some reason each *gc-epoch* resides on its own page
2:55:51
stassats
why is it pinned for more than two calls to (gc)?
3:00:26
stassats
what happens if i write to the old *gc-epoch* cons
3:16:27
stassats
ok, each cons is residing on its own page, using a lot of pages but reporting a low number of bytes used, so it's never reaches the trigger
3:19:11
stassats
i think that's new after we wipe non pinned objects, effectively blowing up usages
3:19:35
stassats
i think the trigger should be changed to the number of pages used, not bytes allocated
3:25:20
stassats
or shouldn't bytes_allocated includes wasted space
3:35:01
pfdietz
This sounds important, and assuming you fix it it should go in monthly release notes.
3:35:29
stassats
eh, i'm not sure it's visible anywhere outside of (loop (gc)), a pathological case
3:35:38
stassats
but i'm using (loop (gc)) for testing
3:38:08
stassats
i suppose i need to prove that first
3:39:22
stassats
by trying to emulate what gc does
3:48:09
stassats
difficult, (loop (gc)) is just too perfect
Tuesday, 18th of December 2018, 5:49:53 UTC