[Commonqt-devel] Qt Tutorial: Memory Fault
Me again ... Doing (ql:quickload :qt) (qt:ensure-smoke :qtcore) (qt:ensure-smoke :qtgui) (ql:quickload :qt-tutorial) and finally (qt-conv:main) results in the following errors: SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST Ok, so maybe I am running into issues as described on "Known issues", "Callbacks from threads" - am I? Thanks again for looking at this. Regards Frank
Frank Goenninger <frgo@me.com> writes:
Me again ...
Doing
(ql:quickload :qt)
(qt:ensure-smoke :qtcore) (qt:ensure-smoke :qtgui)
(ql:quickload :qt-tutorial)
and finally
(qt-conv:main)
results in the following errors:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
Ok, so maybe I am running into issues as described on "Known issues", "Callbacks from threads" - am I?
Thanks again for looking at this.
There's no callbacks from threads here. Make sure that libsmoke and libcommonqt were compiled and are using the same version of Qt. -- With best regards, Stas.
Am 26.04.14 11:20 schrieb "Stas Boukarev" unter <stassats@gmail.com>:
Frank Goenninger <frgo@me.com> writes:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
There's no callbacks from threads here. Make sure that libsmoke and libcommonqt were compiled and are using the same version of Qt.
Maybe I'm misinterpreting something, but this line 1: ("foreign function: call_into_lisp") from the backtrace as shown in the lisp paste is a callback from C to Lisp for me. And right in that function hell starts ... To be honest I haven't looked at the sources of Qt yet (I don't have them installed as my disk space is a scarce resource). I am still hoping for someone having had the same problem. Thanks again for helping out. Kind regards Frank
Frank Gönninger <frank.goenninger@consequor.de> writes:
Am 26.04.14 11:20 schrieb "Stas Boukarev" unter <stassats@gmail.com>:
Frank Goenninger <frgo@me.com> writes:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
There's no callbacks from threads here. Make sure that libsmoke and libcommonqt were compiled and are using the same version of Qt.
Maybe I'm misinterpreting something, but this line
1: ("foreign function: call_into_lisp")
from the backtrace as shown in the lisp paste is a callback from C to Lisp for me. And right in that function hell starts ... It is a callback from the signal handler, which was triggered by the memory fault.
To be honest I haven't looked at the sources of Qt yet (I don't have them installed as my disk space is a scarce resource). You don't need the sources of Qt. You just need to have a single consistent Qt version for compiling and running smoke and commonqt.
-- With best regards, Stas.
Unfortunately it seems to be a problem with Mac OS X, see comments for https://bugreports.qt-project.org/browse/QTBUG-7393 Seems like the only fix is to run QApplication from the main thread which doesn't seem to be possible with threaded SBCL. Not sure whether there are other workarounds :( On Sat, Apr 26, 2014 at 8:07 PM, Stas Boukarev <stassats@gmail.com> wrote:
Frank Gönninger <frank.goenninger@consequor.de> writes:
Am 26.04.14 11:20 schrieb "Stas Boukarev" unter <stassats@gmail.com>:
Frank Goenninger <frgo@me.com> writes:
SBCL error output: http://paste.lisp.org/+31SS SBCL backtrace: http://paste.lisp.org/+31ST
There's no callbacks from threads here. Make sure that libsmoke and libcommonqt were compiled and are using the same version of Qt.
Maybe I'm misinterpreting something, but this line
1: ("foreign function: call_into_lisp")
from the backtrace as shown in the lisp paste is a callback from C to Lisp for me. And right in that function hell starts ... It is a callback from the signal handler, which was triggered by the memory fault.
To be honest I haven't looked at the sources of Qt yet (I don't have them installed as my disk space is a scarce resource). You don't need the sources of Qt. You just need to have a single consistent Qt version for compiling and running smoke and commonqt.
-- With best regards, Stas.
_______________________________________________ Commonqt-devel mailing list Commonqt-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/commonqt-devel
-- Ivan Shvedunov <ivan4th@gmail.com> ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 2807
Unfortunately it seems to be a problem with Mac OS X, see comments for https://bugreports.qt-project.org/browse/QTBUG-7393 Seems like the only fix is to run QApplication from the main thread which doesn't seem to be possible with threaded SBCL. Not sure whether there are other workarounds :( It is possible with threaded SBCL, the initial REPL thread is the main
Ivan Shvedunov <ivan4th@gmail.com> writes: thread. -- With best regards, Stas.
Indeed, sorry for my mistake. Note that when using SLIME the REPL you see in *slime-repl* buffer is not the main one. So you may try the code without SLIME to see whether the problem is indeed thread-related. On Sat, Apr 26, 2014 at 8:25 PM, Stas Boukarev <stassats@gmail.com> wrote:
Ivan Shvedunov <ivan4th@gmail.com> writes:
Unfortunately it seems to be a problem with Mac OS X, see comments for https://bugreports.qt-project.org/browse/QTBUG-7393 Seems like the only fix is to run QApplication from the main thread which doesn't seem to be possible with threaded SBCL. Not sure whether there are other workarounds :( It is possible with threaded SBCL, the initial REPL thread is the main thread.
-- With best regards, Stas.
-- Ivan Shvedunov <ivan4th@gmail.com> ;; My GPG fingerprint is: 2E61 0748 8E12 BB1A 5AB9 F7D0 613E C0F8 0BC5 2807
participants (4)
-
Frank Goenninger -
Frank Gönninger -
Ivan Shvedunov -
Stas Boukarev