libera/#sbcl - IRC Chatlog
Search
9:26:32
occ
phoe: why (declaim (optimize (speed 0) (space 0) (safety 3) (debug 3))) don't affect compiler's behaviour? Ltk code(make-instance) optimized?
12:22:53
McParen
I have encountered a weird bug when using sbcl to access ncurses from cffi: something happened during the last 6-8 weeks, i guess an glibc update, so that foreign arrays cant be accessed any more with sbcl+cffi, they result in an error of the type "CORRUPTION WARNING in SBCL pid 3962 tid 3962: Memory fault at 0x7f849546f5c0"
12:24:23
McParen
but ONLY when a binary is produced, when called interactively, everything runs as before. it does not depend on any single sbcl version, i've randomly tried various version released during the last year.
12:26:03
McParen
it crashes (by getting into the debugger and producing the above error) reliably when saved and run.
12:27:55
|3b|
do you use any FFI libraries that might try to initialize foreign libraries when loaded?
12:27:56
McParen
i have old builds (end of november) where it still works like it did the years before, but everything from, say, 2023 on, dispays that memory error
12:28:59
McParen
i also dont think that its an sbcl problem, since it does not deend on the sbcl version.
12:29:33
McParen
something changed, whether it is sbcl or the underlying system, and I'm trying to find out what it is.
12:30:09
McParen
as i said, i've tried various sbcl versions which i ised without problems during the last years, and they all now display the same error.
12:31:30
McParen
but what _could_ it possibly be, when my end-of-november builds work and new builds with the same sbcl and same cffi and without any changes now fail?
12:34:58
|3b|
there isn't much people can usefully determine from a single access, other that "that works iff the pointer is valid", and by extension "it didn't work, so you pointer is invalid"
12:35:42
McParen
I'm trying to find out what possibly could have changed because old sbcl is obvious not and old code versions also obviously did not.
12:35:57
scymtym
just to be clear since this hasn't been said explicitly: the fact that accessing foreign memory in certain way worked before does not mean the code is correct. it may have worked (or at least not crashed) by accident before
12:38:45
|3b|
i guess another possibility is that the old binary is loading a different .so than the new ones, and it works differently enough to either break code or expose a bug
12:57:02
stassats`
(defparameter acs-map-array (cffi:foreign-symbol-pointer "acs_map")) runs at build time, does it not?
12:58:49
McParen
how to explain that it worked for years and then suddenly the last few weeks started causing problems?
13:00:51
McParen
this foreign array isnt allocated by me, but by ncurses, i am just accessing its contents
13:02:38
|3b|
you can allocate and load, you just can't save pointers and expect them to work after a load :p (not loading is probably a good enough approximation though)
13:04:34
|3b|
yeah, but some libs do too much wacky stuff to work even without image dumping involved :/
14:13:48
karlosz
stassats: well, getting it to work is not the hard part, but do you think something like eg.
14:15:40
stassats`
saying "well, if it's executed then it will be a redifinition" but imagine instead of nil it's (unless (fboundp 'foo) (defun foo))
14:17:47
stassats`
but i suppose the load time redifinition warning is good enough for that anyway, who only compiles code?
14:19:30
stassats`
more useful would be type information, arg mismatch etc., as that is not handled at load time
14:20:15
karlosz
if we had the compiler emit a proclaim with the derived type info that only gets executed at load time that would work
14:20:32
karlosz
i mean it wouldn't help with using that type information later in the file but that is an impossible task anyway
14:25:13
stassats`
it can't proceed loading in an orderly fashion, only escaping the whole LOAD call
14:29:39
karlosz
either way, its probably not worht complaining at compile time anyway like you said
14:30:07
stassats`
is throwing from load a defined behavior anyway? does everything that precede it remain in a good shape?
14:30:56
stassats`
karlosz: i don't think that's complicated, just need to tell if defun is always executed, unless there's a THROW or SIGNAL
14:31:28
stassats`
why not - the order of load-time-value forms is not specified? what it if it's done at the end?
14:32:00
stassats`
" It is guaranteed that the evaluation of form will take place only once when the file is loaded, but the order of evaluation with respect to the evaluation of top level forms in the file is implementation-dependent."
14:33:36
stassats`
a fasl with "(defun a () (load-time-value (value))) (throw 'escape t)", but (value) is evaluated only at the end of loading the fasl
14:41:06
stassats`
"If the file named by filespec is successfully loaded, load returns true." what does it mean to be successfully loaded?
14:44:16
stassats`
so you can't throw from load because you don't know if there's load-time-value used or not
14:44:45
karlosz
you can;t use load-time-value with deterministic results if you throw from it somewhere
14:45:58
stassats`
does that mean you can't call functions that have load-time-value before the fasl has finished loading?
14:46:56
karlosz
to write protable code you must write LTV forms such that they execute the same way regardless of how they are ordered to other top level forms
14:49:47
karlosz
how does the user know that the program they wrote is using + correctly with the right argument types?
14:51:33
karlosz
did you engage in this socratic dialog to tell me you don't like the way LTV is specified?
14:53:11
karlosz
either explcitly with THROW or as a natural by product of whatever the lisp file is doing (artihmetic errors, exception situations, i.o problems ....)
14:53:48
karlosz
if i write a script to query the file system and the file system returns an exception i should be able to handle that exception outside the LOAD
14:54:26
karlosz
so you should suspend at least some expectation that it will always do the expected thing
14:55:53
karlosz
if i call a function FOO and it throws an exception you would accept that as normal behavior right
14:55:59
stassats`
what can be said about LOAD that exited non locally? are all effects that happen after the exit discarded?
14:56:41
karlosz
if i write a lisp file that has (print "foo" )(print "bar") (print "cake") (foo) ...
14:56:57
stassats`
if there's a top level defun after THROW, does the definition of that defun not exist?
14:57:59
karlosz
its sitting in the fasl but the fasl loader never got to executing the load-toplevel action of the DEFUN
15:00:45
stassats`
in what order things are allowed to happen, which do not produce visible behavior
15:01:12
stassats`
if functions in the same file can't be redefined at runtime how does that square with exceptions?
15:02:01
karlosz
i.e. it really matters more what the loader executes, not what has been done at compile time
15:02:44
karlosz
i think mayve we should even get rid of compile time warnings for duplicate definitions entirely and only warn at load time
16:40:16
Krystof
I don't think we should get rid of compile-time warnings for duplicate definitions within the same file, even if we can't make them 100% correct, because users should have a clear way of not having the warnings: to declaim the name of the function notinline (or to not have redefinitions)
16:41:00
Krystof
I believe that compile-time warnings are more useful than load-time ones, because there is plenty of software out there that notices and surfaces compile-time warnings (slime, asdf) to the user, whereas not very much that I know of considers warnings at load-time