-
Notifications
You must be signed in to change notification settings - Fork 8
Tests fail: Unhandled memory fault at #x0. #24
Comments
Which SBCL version (or commit) is that? And which GTK/G... versions? I'll try reproducing it, though actually I'll only be able to check with a different SBCL version, GTK is too much of a hassle. |
SBCL 1.4.4. |
GTK 3.22.30. |
Works for me unfortunately. SBCL On a fresh process, with
That's very likely the call that failed in the output above and it really shouldn't, since that goes straight to the FFI level. |
On Guix, the filesystem is slightly different and the libraries are found in The result is as follows: > sbcl
This is SBCL 1.4.4, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (ql:quickload :cffi)
To load "cffi":
Load 1 ASDF system:
cffi
; Loading "cffi"
.
(:CFFI)
* (push (format nil "~a/.guix-profile/lib/" (uiop:getenv "HOME")) cffi:*foreign-library-directories*)
("/home/ambrevar/.guix-profile/lib/")
* (ql:quickload "cl-cffi-gtk")
To load "cl-cffi-gtk":
Load 1 ASDF system:
cl-cffi-gtk
; Loading "cl-cffi-gtk"
..............
("cl-cffi-gtk")
* (cffi:with-foreign-object (parameters '(:struct gobject::g-parameter) 0) (gobject::g-object-newv "GtkButton" 0 parameters))
#.(SB-SYS:INT-SAP #X00788180)
* And it works. The above error is produced when the tests are run from the Guix' asdf-build-system which is used to package Common Lisp code. |
That's Quicklisp's |
Oh, did not notice that. Shouldn't we let Quicklisp know? I've tried this repo and got the same result. |
Be my guest, quicklisp/quicklisp-projects#1302.
Okay. Right now I have no real idea what else to try, except attach |
I've opened an issue on Guix' bug tracker, we might get some help from there. |
This stacktrace looks a lot as if source-func-cb funcall:ed nil. If so, it might be another aspect of stable-pointers not being thread-safe. |
You are right, I've come to notice the same thing recently.
Can you reproduce the issue with tests by the way?
|
Using side-threads, the following triggers an error pretty reliably.
This relies on my cl-gtk-frank, but it's just a callback for 'clicked' on a button which sets the text of a label. The stack-trace I get is
This doesn't look exactly like your example, but I'm thinking that the difference in SBCL version (2.0.1 here) might account for that. |
@bpatrikm I've edited your post to fix the formatting. Also please post a self-contained example whenever possible, I can't go chase dependencies for debugging.
Is that a library? This is what I've tried:
And that works fairly well on Clozure CL, can't try right now on SBCL. Note that @bpatrikm Could you increase your debug level for a better stacktrace? Like |
This produces the same error for me.
Note that the error is triggered when the button is clicked. There is a random element to it, but it triggers nine times out of ten for me.
Changing the debug level makes no difference for me (in this or the former example).
By 'side-threads', I only mean the concept that new threads are created within the callback. Gtk has a concept of a 'main thread' - and I mean any other threads than that. More important than an example, is to look at the lack of thread safety in glib.stable-pointer.lisp and gdk.threads.lisp. Although producing an error on demand is a bit fiddly, it's obvious one will happen sooner or later if stable-pointer is used concurrantly. Now, anytime you cause that to happen through using 'within-gtk-thread', you can also prevent it by setting up your own mutexes. But I have come to believe, that it may also happen that callbacks are invoked in side-threads, although the gtk documentations says it won't. https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
|
Okay, I'll see if I can reproduce it on SBCL.
Perhaps, yes, if you put a mutex in/around I also blame concurrency issues on some other trouble I've encountered, it's just impossible to debug. |
I made those edits in glib.stable-pointer.lisp in my repo-copy. I'm wary of making a pull request of it, because I really don't know if it might cause other problems. But it does get rid of this crash. |
Can confirm on SBCL and also your fix makes it disappear, I'll do some more testing with a bigger project, but feel free to make a PR for it.
could you make that
so it matches other calls to |
I'm trying to package cl-cffi-gtk for Guix but tests are failing:
Can anyone reproduce?
The text was updated successfully, but these errors were encountered: