From: Leo <sd...@gm...> - 2010-05-24 13:16:49
|
Hello, I have found when running plplot on another thread, none of the drivers including qt on linux works well; they all crash the underlying lisp. The only driver that works for me is aqt on darwin but sadly my server is running linux - openSUSE 11.0 (X86-64). For information. Leo -- CCL-USER> (if you fail to plan (plan to fail)) |
From: Leo <sd...@gm...> - 2010-05-24 13:48:31
|
On 2010-05-24 14:16 +0100, Leo wrote: > Hello, > > I have found when running plplot on another thread, none of the drivers > including qt on linux works well; they all crash the underlying lisp. > The only driver that works for me is aqt on darwin but sadly my server > is running linux - openSUSE 11.0 (X86-64). > > For information. > > Leo It seems this is due to the fact my code is not robust. Anyone here can help make it robust? Thanks. (defmacro with-plot-window (&body body) (let ((xx (gensym "XX")) (yy (gensym "YY")) (corners (gensym "CORNERS"))) `(let ((,xx (make-array 0 :adjustable t :fill-pointer t)) (,yy (make-array 0 :adjustable t :fill-pointer t)) (,corners (list 0 0 0 0))) (labels ((adjust-corners (x y) (when (< x (first ,corners)) (setf (first ,corners) x)) (when (> x (second ,corners)) (setf (second ,corners) x)) (when (< y (third ,corners)) (setf (third ,corners) y)) (when (> y (fourth ,corners)) (setf (fourth ,corners) y)) ,corners) (plot-point (x y &optional (symbol-type 2)) (plclear) (apply #'plwind (adjust-corners x y)) (plcol0 15) ; black foreground (plbox "bcnst" 0 0 "bcnstv" 0 0) (pllab "(x)" "(y)" "cl-plplot") (plcol0 1) ; red foreground (vector-push-extend x ,xx) (vector-push-extend y ,yy) (plpoin ,xx ,yy symbol-type) (plline ,xx ,yy) (plflush))) (plsdev *plot-device*) (plscol0 0 255 255 255) ; swap black and white (plscol0 15 0 0 0) (plinit) (plwid 1) (pladv 0) (plvsta) (unwind-protect (progn ,@body) (plend)))))) ;; test (with-plot-window (loop for (x y) in '((1 1) (-2 4) (3 9) (-4 16) (5 25)) do (plot-point x y) (sleep 1))) Leo -- CCL-USER> (if you fail to plan (plan to fail)) |
From: Hazen B. <hba...@ma...> - 2010-05-24 20:03:16
|
Leo wrote: > On 2010-05-24 14:16 +0100, Leo wrote: >> Hello, >> >> I have found when running plplot on another thread, none of the drivers >> including qt on linux works well; they all crash the underlying lisp. >> The only driver that works for me is aqt on darwin but sadly my server >> is running linux - openSUSE 11.0 (X86-64). >> >> For information. >> >> Leo > > It seems this is due to the fact my code is not robust. Anyone here can > help make it robust? Thanks. > > (defmacro with-plot-window (&body body) > (let ((xx (gensym "XX")) > (yy (gensym "YY")) > (corners (gensym "CORNERS"))) > `(let ((,xx (make-array 0 :adjustable t :fill-pointer t)) > (,yy (make-array 0 :adjustable t :fill-pointer t)) > (,corners (list 0 0 0 0))) > (labels ((adjust-corners (x y) > (when (< x (first ,corners)) > (setf (first ,corners) x)) > (when (> x (second ,corners)) > (setf (second ,corners) x)) > (when (< y (third ,corners)) > (setf (third ,corners) y)) > (when (> y (fourth ,corners)) > (setf (fourth ,corners) y)) > ,corners) > (plot-point (x y &optional (symbol-type 2)) > (plclear) > (apply #'plwind (adjust-corners x y)) > (plcol0 15) ; black foreground > (plbox "bcnst" 0 0 "bcnstv" 0 0) > (pllab "(x)" "(y)" "cl-plplot") > (plcol0 1) ; red foreground > (vector-push-extend x ,xx) > (vector-push-extend y ,yy) > (plpoin ,xx ,yy symbol-type) > (plline ,xx ,yy) > (plflush))) > (plsdev *plot-device*) > (plscol0 0 255 255 255) ; swap black and white > (plscol0 15 0 0 0) > (plinit) > (plwid 1) > (pladv 0) > (plvsta) > (unwind-protect (progn ,@body) > (plend)))))) > > ;; test > (with-plot-window > (loop for (x y) in '((1 1) (-2 4) (3 9) (-4 16) (5 25)) > do (plot-point x y) > (sleep 1))) > > > Leo > Are you getting any sort of error message? A backtrace? Are multiple threads trying to run your code at the same time? -Hazen |
From: Leo <sd...@gm...> - 2010-05-24 20:47:28
|
On 2010-05-24 21:03 +0100, Hazen Babcock wrote: > Are you getting any sort of error message? A backtrace? Are multiple > threads trying to run your code at the same time? I don't why I didn't get a backtrace even when running lisp in gdb. What I observed is this: 1. If I start lisp in terminal, and run the test code in it, it works, no crash, a few drivers like qtwidget xcairo etc. all work fine. 2. If I use slime to connect to it, and run the test code in slime, it starts a new thread, if I hit SPC on the plot window the whole thing goes down - seg fault. Leo -- CCL-USER> (if you fail to plan (plan to fail)) |
From: Leo <sd...@gm...> - 2010-05-25 11:33:02
|
On 2010-05-25 10:54 +0100, Andrew Ross wrote: > So just to be clear, you have only observed the crash with the following > interactive devices: xcairo, qtwidget > > Have you tried xwin on Linux? This has far fewer external dependencies > and the thread support for screen refresh is in the driver (so we have > more chance of debugging!) I have been doing a round trip. Some time ago xwin and xcairo crashed lisp due to closing the plot window by clicking on the close button. So I moved to qtwidget. But qtwidget and some others crashed lisp when running in another thread (which is what happens when running in slime). XWIN seems to be working fine. See this: http://imagebin.org/98248 except I need to make sure I remember to exit the plot window with SPC. Otherwise the plot window will not respond to any user interaction and will remain on the screen until lisp exits. > You have not observed problems with psc or svg drivers. What about the > qt or cairo file based drivers (e.g. pscairo / epsqt)? EPSQT has the same issue as qtwidget. PSCAIRO has the same issue as xcairo. > You might try running with valgrind as an alternative to gdb. It tends > to be quite good at finding issues related to memory access / memory > allocation. I am not familiar with valgrind and i got "Unsupported arch_prtctl option" trying to use it by running: valgrind devel/ccl/lx86cl64 > Andrew Thanks. Leo |
From: Andrew R. <and...@us...> - 2010-05-25 12:06:40
|
On Tue, May 25, 2010 at 12:32:37PM +0100, Leo wrote: > On 2010-05-25 10:54 +0100, Andrew Ross wrote: > > So just to be clear, you have only observed the crash with the following > > interactive devices: xcairo, qtwidget > > > > Have you tried xwin on Linux? This has far fewer external dependencies > > and the thread support for screen refresh is in the driver (so we have > > more chance of debugging!) > > I have been doing a round trip. Some time ago xwin and xcairo crashed > lisp due to closing the plot window by clicking on the close button. So > I moved to qtwidget. > > But qtwidget and some others crashed lisp when running in another thread > (which is what happens when running in slime). > > XWIN seems to be working fine. See this: http://imagebin.org/98248 > except I need to make sure I remember to exit the plot window with SPC. > Otherwise the plot window will not respond to any user interaction and > will remain on the screen until lisp exits. Right. That helps. Alan's comments about using the svn version apply here. I've recently fixed up some of the issues related to closing the window with the close button for the xwin driver so you may find that works. > > You have not observed problems with psc or svg drivers. What about the > > qt or cairo file based drivers (e.g. pscairo / epsqt)? > > EPSQT has the same issue as qtwidget. PSCAIRO has the same issue as > xcairo. Right, that is useful to know. It's not an issue with the interactive drivers then, but something deeper. Qt in particular has it's own thread support, and it is possible that something in there is interfering with your lisp thread support. I will look again at the qt mutex code to check for possible races. > > > You might try running with valgrind as an alternative to gdb. It tends > > to be quite good at finding issues related to memory access / memory > > allocation. > > I am not familiar with valgrind and i got "Unsupported arch_prtctl > option" trying to use it by running: > > valgrind devel/ccl/lx86cl64 OK. It's probably more tricky with lisp. Your backtrace already provides some clues. Andrew |
From: Hazen B. <hba...@ma...> - 2010-05-24 21:05:02
|
Leo wrote: > On 2010-05-24 21:03 +0100, Hazen Babcock wrote: >> Are you getting any sort of error message? A backtrace? Are multiple >> threads trying to run your code at the same time? > > I don't why I didn't get a backtrace even when running lisp in gdb. > > What I observed is this: > > 1. If I start lisp in terminal, and run the test code in it, it works, > no crash, a few drivers like qtwidget xcairo etc. all work fine. > > 2. If I use slime to connect to it, and run the test code in slime, it > starts a new thread, if I hit SPC on the plot window the whole thing > goes down - seg fault. So in slime your code runs fine, updating the plot, etc, but once it is done and you press the space bar everything crashes? However, if you do the same thing from lisp in the terminal the lisp process continues to run after the space bar is pressed? Could you try to simplify it to the minimal number of instructions for bad results? For example, does this also crash? (plsdev *plot-device*) (plinit) (plend) This is a long shot, but does using (plend1) instead work? What Lisp (and version #) are you using? -Hazen |
From: Leo <sd...@gm...> - 2010-05-24 21:49:51
|
On 2010-05-24 22:04 +0100, Hazen Babcock wrote: > Leo wrote: >> On 2010-05-24 21:03 +0100, Hazen Babcock wrote: >>> Are you getting any sort of error message? A backtrace? Are multiple >>> threads trying to run your code at the same time? > >> >> I don't why I didn't get a backtrace even when running lisp in gdb. >> >> What I observed is this: >> >> 1. If I start lisp in terminal, and run the test code in it, it works, >> no crash, a few drivers like qtwidget xcairo etc. all work fine. >> >> 2. If I use slime to connect to it, and run the test code in slime, it >> starts a new thread, if I hit SPC on the plot window the whole thing >> goes down - seg fault. > > So in slime your code runs fine, updating the plot, etc, but once it is > done and you press the space bar everything crashes? However, if you do > the same thing from lisp in the terminal the lisp process continues to > run after the space bar is pressed? Yes, that's correct. > > Could you try to simplify it to the minimal number of instructions for > bad results? For example, does this also crash? > > (plsdev *plot-device*) > (plinit) > (plend) > > This is a long shot, but does using (plend1) instead work? I am running 'Clozure Common Lisp Version 1.5-r13736M (LinuxX8664)!' This crashes lisp: (progn (plsdev "qtwidget") (plinit) (plclear) (plend1)) Requires two runs and prints this on the terminal (with plend only one run and segfault): ? WARNING: QApplication was not created in the main() thread. *** glibc detected *** /users/b/leo/devel/ccl/lx86cl64: double free or corruption (!prev): 0x000000000072dd00 *** ======= Backtrace: ========= /lib64/libc.so.6[0x7fa2e2971af8] /lib64/libc.so.6(cfree+0x76)[0x7fa2e29736e6] /usr/lib64/libX11.so.6(XFree+0x9)[0x7fa2dc897199] /usr/lib64/libXi.so.6(XCloseDevice+0x8d)[0x7fa2ddc7fabd] /usr/lib64/libQtGui.so.4[0x7fa2df210966] /usr/lib64/libQtGui.so.4(_ZN12QApplicationD0Ev+0x5ab)[0x7fa2df1bfa4b] /users/b/leo/devel/plplot/lib/plplot5.9.5/driversd/qt.so(_Z10closeQtAppv+0x78)[0x7fa2dfeb9558] /users/b/leo/devel/plplot/lib/plplot5.9.5/driversd/qt.so(_Z17plD_tidy_qtwidgetP8PLStream+0x7e)[0x7fa2dfeb96fb] /users/b/leo/devel/plplot/lib/libplplotd.so.9.7.0(plP_tidy+0x99)[0x7fa2e16cf69b] /users/b/leo/devel/plplot/lib/libplplotd.so.9.7.0(c_plend1+0x1f)[0x7fa2e16d5111] /users/b/leo/devel/ccl/lx86cl64(_SPffcall+0x7a)[0x411a3a] ======= Memory map: ======== 00012000-00014000 rwxp 00000000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 00015000-00016000 rwxp 00015000 00:00 0 00400000-0042b000 r-xp 00000000 00:26 145393 /users/b/leo/devel/ccl/lx86cl64 0062a000-0062b000 r-xp 0002a000 00:26 145393 /users/b/leo/devel/ccl/lx86cl64 0062b000-0062c000 rwxp 0002b000 00:26 145393 /users/b/leo/devel/ccl/lx86cl64 0062c000-008b8000 rwxp 0062c000 00:00 0 [heap] 40036000-404fe000 rwxp 40036000 00:00 0 40a13000-40c77000 rwxp 40a13000 00:00 0 40efc000-413c4000 rwxp 40efc000 00:00 0 41dc0000-42288000 rwxp 41dc0000 00:00 0 300000000000-300000209000 r-xp 00002000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 300000209000-30000020a000 rwxp 0020b000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 30000020a000-300000997000 r-xp 0020c000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 300000997000-300000998000 rwxp 00999000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 300000998000-300000c09000 r-xp 0099a000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 300000c09000-300040000000 ---p 300000c09000 00:00 0 300040000000-3000404c9000 rwxp 0113e000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 3000404c9000-302000000000 ---p 3000404c9000 00:00 0 302000000000-302000533000 rwxp 00c0b000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 302000533000-302002540000 rwxp 302000533000 00:00 0 302002540000-307c00000000 ---p 302002540000 00:00 0 307c00000000-307c0004b000 rwxp 307c00000000 00:00 0 307c0004b000-307e00000000 ---p 307c0004b000 00:00 0 307e00000000-307e0000a000 rwxp 01607000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image 307e0000a000-307e3f800000 ---p 307e0000a000 00:00 0 307e3f800000-307e3f84b000 rwxp 307e3f800000 00:00 0 307e3f84b000-308000020000 ---p 307e3f84b000 00:00 0 7fa2d4000000-7fa2d4021000 rwxp 7fa2d4000000 00:00 0 7fa2d4021000-7fa2d8000000 ---p 7fa2d4021000 00:00 0 7fa2db870000-7fa2db8a5000 r-xs 00000000 08:03 118157 /var/run/nscd/dbKH1Nzs (deleted) 7fa2db8a5000-7fa2db90a000 r-xs 00000000 08:03 8509 /var/cache/fontconfig/df311e82a1a24c41a75c2c930223552e-x86-64.cache-2 7fa2db90a000-7fa2db97d000 r-xs 00000000 08:03 8435 /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86-64.cache-2 7fa2db97d000-7fa2db9e2000 r-xs 00000000 08:03 8506 /var/cache/fontconfig/17090aa38d5c6f09fb8c5c354938f1d7-x86-64.cache-2 7fa2db9e2000-7fa2db9e5000 r-xp 00000000 08:05 154031 /usr/lib64/gconv/UTF-16.so 7fa2db9e5000-7fa2dbbe4000 ---p 00003000 08:05 154031 /usr/lib64/gconv/UTF-16.so 7fa2dbbe4000-7fa2dbbe5000 r-xp 00002000 08:05 154031 /usr/lib64/gconv/UTF-16.so 7fa2dbbe5000-7fa2dbbe6000 rwxp 00003000 08:05 154031 /usr/lib64/gconv/UTF-16.sAborted Leo |
From: Alan W. I. <ir...@be...> - 2010-05-24 23:33:06
|
On 2010-05-24 22:49+0100 Leo wrote: > On 2010-05-24 22:04 +0100, Hazen Babcock wrote: >> Leo wrote: >>> On 2010-05-24 21:03 +0100, Hazen Babcock wrote: >>>> Are you getting any sort of error message? A backtrace? Are multiple >>>> threads trying to run your code at the same time? >> >>> >>> I don't why I didn't get a backtrace even when running lisp in gdb. >>> >>> What I observed is this: >>> >>> 1. If I start lisp in terminal, and run the test code in it, it works, >>> no crash, a few drivers like qtwidget xcairo etc. all work fine. >>> >>> 2. If I use slime to connect to it, and run the test code in slime, it >>> starts a new thread, if I hit SPC on the plot window the whole thing >>> goes down - seg fault. >> >> So in slime your code runs fine, updating the plot, etc, but once it is >> done and you press the space bar everything crashes? However, if you do >> the same thing from lisp in the terminal the lisp process continues to >> run after the space bar is pressed? > > Yes, that's correct. > >> >> Could you try to simplify it to the minimal number of instructions for >> bad results? For example, does this also crash? >> >> (plsdev *plot-device*) >> (plinit) >> (plend) >> >> This is a long shot, but does using (plend1) instead work? > > I am running 'Clozure Common Lisp Version 1.5-r13736M (LinuxX8664)!' > > This crashes lisp: > > (progn > (plsdev "qtwidget") > (plinit) > (plclear) > (plend1)) > > Requires two runs and prints this on the terminal (with plend only one > run and segfault): > > ? WARNING: QApplication was not created in the main() thread. > *** glibc detected *** /users/b/leo/devel/ccl/lx86cl64: double free or corruption (!prev): 0x000000000072dd00 *** > ======= Backtrace: ========= > /lib64/libc.so.6[0x7fa2e2971af8] > /lib64/libc.so.6(cfree+0x76)[0x7fa2e29736e6] > /usr/lib64/libX11.so.6(XFree+0x9)[0x7fa2dc897199] > /usr/lib64/libXi.so.6(XCloseDevice+0x8d)[0x7fa2ddc7fabd] > /usr/lib64/libQtGui.so.4[0x7fa2df210966] > /usr/lib64/libQtGui.so.4(_ZN12QApplicationD0Ev+0x5ab)[0x7fa2df1bfa4b] > /users/b/leo/devel/plplot/lib/plplot5.9.5/driversd/qt.so(_Z10closeQtAppv+0x78)[0x7fa2dfeb9558] > /users/b/leo/devel/plplot/lib/plplot5.9.5/driversd/qt.so(_Z17plD_tidy_qtwidgetP8PLStream+0x7e)[0x7fa2dfeb96fb] > /users/b/leo/devel/plplot/lib/libplplotd.so.9.7.0(plP_tidy+0x99)[0x7fa2e16cf69b] > /users/b/leo/devel/plplot/lib/libplplotd.so.9.7.0(c_plend1+0x1f)[0x7fa2e16d5111] > /users/b/leo/devel/ccl/lx86cl64(_SPffcall+0x7a)[0x411a3a] > ======= Memory map: ======== > 00012000-00014000 rwxp 00000000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 00015000-00016000 rwxp 00015000 00:00 0 > 00400000-0042b000 r-xp 00000000 00:26 145393 /users/b/leo/devel/ccl/lx86cl64 > 0062a000-0062b000 r-xp 0002a000 00:26 145393 /users/b/leo/devel/ccl/lx86cl64 > 0062b000-0062c000 rwxp 0002b000 00:26 145393 /users/b/leo/devel/ccl/lx86cl64 > 0062c000-008b8000 rwxp 0062c000 00:00 0 [heap] > 40036000-404fe000 rwxp 40036000 00:00 0 > 40a13000-40c77000 rwxp 40a13000 00:00 0 > 40efc000-413c4000 rwxp 40efc000 00:00 0 > 41dc0000-42288000 rwxp 41dc0000 00:00 0 > 300000000000-300000209000 r-xp 00002000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 300000209000-30000020a000 rwxp 0020b000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 30000020a000-300000997000 r-xp 0020c000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 300000997000-300000998000 rwxp 00999000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 300000998000-300000c09000 r-xp 0099a000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 300000c09000-300040000000 ---p 300000c09000 00:00 0 > 300040000000-3000404c9000 rwxp 0113e000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 3000404c9000-302000000000 ---p 3000404c9000 00:00 0 > 302000000000-302000533000 rwxp 00c0b000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 302000533000-302002540000 rwxp 302000533000 00:00 0 > 302002540000-307c00000000 ---p 302002540000 00:00 0 > 307c00000000-307c0004b000 rwxp 307c00000000 00:00 0 > 307c0004b000-307e00000000 ---p 307c0004b000 00:00 0 > 307e00000000-307e0000a000 rwxp 01607000 00:26 145392 /users/b/leo/devel/ccl/lx86cl64.image > 307e0000a000-307e3f800000 ---p 307e0000a000 00:00 0 > 307e3f800000-307e3f84b000 rwxp 307e3f800000 00:00 0 > 307e3f84b000-308000020000 ---p 307e3f84b000 00:00 0 > 7fa2d4000000-7fa2d4021000 rwxp 7fa2d4000000 00:00 0 > 7fa2d4021000-7fa2d8000000 ---p 7fa2d4021000 00:00 0 > 7fa2db870000-7fa2db8a5000 r-xs 00000000 08:03 118157 /var/run/nscd/dbKH1Nzs (deleted) > 7fa2db8a5000-7fa2db90a000 r-xs 00000000 08:03 8509 /var/cache/fontconfig/df311e82a1a24c41a75c2c930223552e-x86-64.cache-2 > 7fa2db90a000-7fa2db97d000 r-xs 00000000 08:03 8435 /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86-64.cache-2 > 7fa2db97d000-7fa2db9e2000 r-xs 00000000 08:03 8506 /var/cache/fontconfig/17090aa38d5c6f09fb8c5c354938f1d7-x86-64.cache-2 > 7fa2db9e2000-7fa2db9e5000 r-xp 00000000 08:05 154031 /usr/lib64/gconv/UTF-16.so > 7fa2db9e5000-7fa2dbbe4000 ---p 00003000 08:05 154031 /usr/lib64/gconv/UTF-16.so > 7fa2dbbe4000-7fa2dbbe5000 r-xp 00002000 08:05 154031 /usr/lib64/gconv/UTF-16.so > 7fa2dbbe5000-7fa2dbbe6000 rwxp 00003000 08:05 154031 /usr/lib64/gconv/UTF-16.sAborted Hi Leo: Sorry if I missed this earlier in the thread, but what version of PLplot? If you are not doing so already, could you try the svn trunk version of PLplot? We are in the last stage of preparing that for our next release, and it has many bug fixes compared to the previous release. Just to simplify possibilities, could you try the psc device instead? The associated ps device driver has no external library dependencies. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Leo <sd...@gm...> - 2010-05-28 09:40:47
|
On 2010-05-27 23:08 +0100, Andrew Ross wrote: > debugger invoked on a UNDEFINED-FUNCTION in thread #<THREAD "initial > thread" RUNNING {100367F441}>: The function PLSDEV is undefined. > > > I don't know whether this is a problem between versions of plplot and > cl-plplot (both installed as Ubuntu packages). I think it could be due to the 'cffi'¹ package. I use the version from the darcs repo: http://common-lisp.net/project/cffi/darcs/cffi/. I had problems with the current version 0.10.5 when trying to use GSL (for lisp). But I am not entirely sure. I wonder if Hazen can help out here ;) Leo Footnotes: ¹ http://common-lisp.net/project/cffi/ |
From: Hazen B. <hba...@ma...> - 2010-05-28 17:04:03
|
Leo wrote: > On 2010-05-27 23:08 +0100, Andrew Ross wrote: >> debugger invoked on a UNDEFINED-FUNCTION in thread #<THREAD "initial >> thread" RUNNING {100367F441}>: The function PLSDEV is undefined. >> >> >> I don't know whether this is a problem between versions of plplot and >> cl-plplot (both installed as Ubuntu packages). > > I think it could be due to the 'cffi'¹ package. I use the version from > the darcs repo: http://common-lisp.net/project/cffi/darcs/cffi/. > > I had problems with the current version 0.10.5 when trying to use GSL > (for lisp). > > But I am not entirely sure. I wonder if Hazen can help out here ;) Perhaps :), but it will be a few days. Meanwhile my guess is that the qtwidget will not work for you unless there is some way to force it to be run in the main thread. If you look at the error message in your message on 5-24-10 it states: ? WARNING: QApplication was not created in the main() thread. In my experience with Qt (mostly PyQt) you are asking for trouble if you try and do anything GUI related in a thread that is not the main thread. As I recall you can (with some pain) configure slime to work with a single threaded lisp? If you do that, do you still see the same crashes? What was the problem with the xcairo driver? You mentioned that it crashed when you clicked on the close box, but that should be fixed. Is there anything else? -Hazen |
From: Leo <sd...@gm...> - 2010-05-28 17:53:31
|
On 2010-05-28 18:03 +0100, Hazen Babcock wrote: > What was the problem with the xcairo driver? You mentioned that it > crashed when you clicked on the close box, but that should be fixed. Is > there anything else? The xcairo crashes lisp too (usually after 2-3 times of running the test code) like this regardless of how I exit the plot window: ? exception in foreign context Exception occurred while executing foreign code at strcmp + 148 ? for help [29540] Clozure CL kernel debugger: b current thread: tcr = 0x412ca7c0, native thread ID = 0x73be, interrupts enabled (#x00007FE81B49E7E0) #x0000302001587D74 : #<Function C-PLBOX #x0000302001587BBF> + 437 (#x00007FE81B49E850) #x00003020015876AC : #<Function PLBOX #x000030200158751F> + 397 (#x00007FE81B49E8E0) #x0000302001A43C1C : #<Function PLOT-POINT #x0000302001A43ADF> + 317 (#x00007FE81B49E938) #x0000302001A6713C : #<Anonymous Function #x0000302001A66E2F> + 781 (#x00007FE81B49E9C0) #x0000300000508F94 : #<Function CHEAP-EVAL #x0000300000508F2F> + 101 (#x00007FE81B49E9F8) #x00003020007675AC : #<Function (:INTERNAL INTERACTIVE-EVAL) #x000030200076754F> + 93 (#x00007FE81B49EA18) #x000030200070E614 : #<Function CALL-WITH-RETRY-RESTART #x000030200070E3FF> + 533 (#x00007FE81B49EA70) #x0000302000773B24 : #<Function CALL-WITH-BUFFER-SYNTAX #x0000302000773A4F> + 213 (#x00007FE81B49EAB0) #x00003000005055E4 : #<Function CALL-CHECK-REGS #x00003000005054FF> + 229 (#x00007FE81B49EAE8) #x0000300000508F94 : #<Function CHEAP-EVAL #x0000300000508F2F> + 101 (#x00007FE81B49EB20) #x0000302000769514 : #<Function EVAL-FOR-EMACS #x000030200076917F> + 917 (#x00007FE81B49EC20) #x0000302000726D74 : #<Function (:INTERNAL SPAWN-WORKER-THREAD) #x0000302000726B4F> + 549 (#x00007FE81B49ECA0) #x00003020006C4CCC : #<Function CALL-WITH-DEBUGGER-HOOK #x00003020006C4C0F> + 189 (#x00007FE81B49ED28) #x00003020006FACA4 : #<Function CALL-WITH-BINDINGS #x00003020006FA91F> + 901 (#x00007FE81B49ED80) #x000030200070F33C : #<Function CALL-WITH-CONNECTION #x000030200070EEEF> + 1101 (#x00007FE81B49EE58) #x00003020006FACA4 : #<Function CALL-WITH-BINDINGS #x00003020006FA91F> + 901 (#x00007FE81B49EEB0) #x0000300000471904 : #<Function RUN-PROCESS-INITIAL-FORM #x000030000047162F> + 725 (#x00007FE81B49EF48) #x0000300000472224 : #<Function (:INTERNAL (%PROCESS-PRESET-INTERNAL (PROCESS))) #x000030000047209F> + 389 (#x00007FE81B49EF98) #x000030000044F68C : #<Function (:INTERNAL THREAD-MAKE-STARTUP-FUNCTION) #x000030000044F55F> + 301 [29540] Clozure CL kernel debugger: -- CCL-USER> (if you fail to plan (plan to fail)) |
From: Hazen B. <hba...@ma...> - 2010-05-28 18:14:54
|
Leo wrote: > On 2010-05-28 18:03 +0100, Hazen Babcock wrote: >> What was the problem with the xcairo driver? You mentioned that it >> crashed when you clicked on the close box, but that should be fixed. Is >> there anything else? > > The xcairo crashes lisp too (usually after 2-3 times of running the test > code) like this regardless of how I exit the plot window: This happens only upon exiting? Or at some random point during execution? Sorry to keep asking this, but does this only occur when you are also using slime? If so, can you change how slime interacts with the lisp process so that it does not use interrupts? -Hazen |
From: Leo <sd...@gm...> - 2010-05-28 19:45:24
|
On 2010-05-28 19:14 +0100, Hazen Babcock wrote: > Leo wrote: >> On 2010-05-28 18:03 +0100, Hazen Babcock wrote: >>> What was the problem with the xcairo driver? You mentioned that it >>> crashed when you clicked on the close box, but that should be fixed. Is >>> there anything else? >> >> The xcairo crashes lisp too (usually after 2-3 times of running the test >> code) like this regardless of how I exit the plot window: > > This happens only upon exiting? Or at some random point during execution? > > Sorry to keep asking this, but does this only occur when you are also > using slime? If so, can you change how slime interacts with the lisp > process so that it does not use interrupts? > > -Hazen with help from #lisp, I have found a way to reproduce an 'Unhandled memory fault at #x90' without using slime: If you have http://common-lisp.net/project/bordeaux-threads/ installed: run this two or three times get to the error: (bt:make-thread (lambda () (with-plot-window (loop for (x y) in '((1 1) (-2 4) (3 9) (-4 16) (5 25)) do (plot-point x y) (sleep 1)))) :name "test-bug") where (defparameter *plot-device* "xcairo") See: http://paste.lisp.org/display/105741. Leo |
From: Hazen B. <hba...@ma...> - 2010-05-29 18:52:07
|
Leo wrote: > On 2010-05-28 19:14 +0100, Hazen Babcock wrote: >> This happens only upon exiting? Or at some random point during execution? >> >> Sorry to keep asking this, but does this only occur when you are also >> using slime? If so, can you change how slime interacts with the lisp >> process so that it does not use interrupts? >> >> -Hazen > > with help from #lisp, I have found a way to reproduce an 'Unhandled > memory fault at #x90' without using slime: > > If you have http://common-lisp.net/project/bordeaux-threads/ installed: > > run this two or three times get to the error: > > (bt:make-thread (lambda () (with-plot-window > (loop for (x y) in '((1 1) (-2 4) (3 9) (-4 16) (5 25)) > do (plot-point x y) > (sleep 1)))) :name "test-bug") > > > where (defparameter *plot-device* "xcairo") > > See: http://paste.lisp.org/display/105741. This problem I think we have seen before: http://www.mail-archive.com/plp...@li.../msg02032.html Can you try again using plend1 instead? -Hazen |
From: Leo <sd...@gm...> - 2010-05-29 20:43:11
|
On 2010-05-29 19:51 +0100, Hazen Babcock wrote: > This problem I think we have seen before: > http://www.mail-archive.com/plp...@li.../msg02032.html > > Can you try again using plend1 instead? > > -Hazen Thank you for this. It seems the problem goes away with plend1 with my brief testing just now. Leo |
From: Leo <sd...@gm...> - 2010-05-25 12:33:36
|
On 2010-05-25 13:06 +0100, Andrew Ross wrote: >> XWIN seems to be working fine. See this: http://imagebin.org/98248 >> except I need to make sure I remember to exit the plot window with SPC. >> Otherwise the plot window will not respond to any user interaction and >> will remain on the screen until lisp exits. > > Right. That helps. Alan's comments about using the svn version apply > here. I've recently fixed up some of the issues related to closing > the window with the close button for the xwin driver so you may find > that works. It works in that it didn't crash lisp but it also failed to close window instead the window becomes unresponsive and won't exit unless lisp does. >> > You have not observed problems with psc or svg drivers. What about the >> > qt or cairo file based drivers (e.g. pscairo / epsqt)? >> >> EPSQT has the same issue as qtwidget. PSCAIRO has the same issue as >> xcairo. > > Right, that is useful to know. It's not an issue with the interactive > drivers then, but something deeper. Qt in particular has it's own > thread support, and it is possible that something in there is interfering > with your lisp thread support. I will look again at the qt mutex code to > check for possible races. > >> >> > You might try running with valgrind as an alternative to gdb. It tends >> > to be quite good at finding issues related to memory access / memory >> > allocation. >> >> I am not familiar with valgrind and i got "Unsupported arch_prtctl >> option" trying to use it by running: >> >> valgrind devel/ccl/lx86cl64 > > OK. It's probably more tricky with lisp. Your backtrace already provides > some clues. Many thanks in advance. > Andrew Leo -- CCL-USER> (if you fail to plan (plan to fail)) |
From: Andrew R. <and...@us...> - 2010-05-26 22:45:18
|
On Tue, May 25, 2010 at 01:17:55PM +0100, Leo wrote: > On 2010-05-25 13:06 +0100, Andrew Ross wrote: > >> XWIN seems to be working fine. See this: http://imagebin.org/98248 > >> except I need to make sure I remember to exit the plot window with SPC. > >> Otherwise the plot window will not respond to any user interaction and > >> will remain on the screen until lisp exits. > > > > Right. That helps. Alan's comments about using the svn version apply > > here. I've recently fixed up some of the issues related to closing > > the window with the close button for the xwin driver so you may find > > that works. > > It works in that it didn't crash lisp but it also failed to close window > instead the window becomes unresponsive and won't exit unless lisp does. > > >> > You have not observed problems with psc or svg drivers. What about the > >> > qt or cairo file based drivers (e.g. pscairo / epsqt)? > >> > >> EPSQT has the same issue as qtwidget. PSCAIRO has the same issue as > >> xcairo. > > > > Right, that is useful to know. It's not an issue with the interactive > > drivers then, but something deeper. Qt in particular has it's own > > thread support, and it is possible that something in there is interfering > > with your lisp thread support. I will look again at the qt mutex code to > > check for possible races. > > > >> > >> > You might try running with valgrind as an alternative to gdb. It tends > >> > to be quite good at finding issues related to memory access / memory > >> > allocation. > >> > >> I am not familiar with valgrind and i got "Unsupported arch_prtctl > >> option" trying to use it by running: > >> > >> valgrind devel/ccl/lx86cl64 > > > > OK. It's probably more tricky with lisp. Your backtrace already provides > > some clues. > > Many thanks in advance. I've taken a look and it is not immediately obvious what the problem is. Unfortunately I have been unable to recreate the problem with any other language so it must be something related to the threads and lisp. I am no lisp expert, but I tried installing the relevant Ubuntu packages. I've not been able to get your example to work at all. I suspect this is me doing something wrong. Hazen (as author of cl-plplot) are you able to recreate this problem, and if so can you supply instruction on how I might be able to do the same. That way I can begin testing. Thanks Andrew |
From: Leo <sd...@gm...> - 2010-05-27 05:33:22
|
On 2010-05-26 23:45 +0100, Andrew Ross wrote: > I've taken a look and it is not immediately obvious what the problem is. > Unfortunately I have been unable to recreate the problem with any other > language so it must be something related to the threads and lisp. I am no > lisp expert, but I tried installing the relevant Ubuntu packages. I've > not been able to get your example to work at all. I suspect this is me > doing something wrong. Hazen (as author of cl-plplot) are you able to > recreate this problem, and if so can you supply instruction on how I > might be able to do the same. That way I can begin testing. > > Thanks > > Andrew I attached a small image in my reply and so the msg is 20k over limit. The msg Is being held until the list moderator can review it for approval. Cheers, Leo |
From: Maurice L. <mj...@br...> - 2010-05-27 14:36:50
|
On Thursday, May 27, 2010 at 06:33:01 (+0100) Leo writes: > On 2010-05-26 23:45 +0100, Andrew Ross wrote: > > I've taken a look and it is not immediately obvious what the problem is. > > Unfortunately I have been unable to recreate the problem with any other > > language so it must be something related to the threads and lisp. I am no > > lisp expert, but I tried installing the relevant Ubuntu packages. I've > > not been able to get your example to work at all. I suspect this is me > > doing something wrong. Hazen (as author of cl-plplot) are you able to > > recreate this problem, and if so can you supply instruction on how I > > might be able to do the same. That way I can begin testing. > > > > Thanks > > > > Andrew > > I attached a small image in my reply and so the msg is 20k over limit. > > The msg > > Is being held until the list moderator can review it for approval. > > Cheers, > Leo Thanks for bringing that to my attention, msg approved. -- Maurice LeBrun |
From: Leo <sd...@gm...> - 2010-05-25 03:54:38
|
On 2010-05-25 00:32 +0100, Alan W. Irwin wrote: > Hi Leo: > > Sorry if I missed this earlier in the thread, but what version of PLplot? I am using the latest svn version. > If you are not doing so already, could you try the svn trunk version of > PLplot? We are in the last stage of preparing that for our next release, > and it has many bug fixes compared to the previous release. > > Just to simplify possibilities, could you try the psc device > instead? The associated ps device driver has no external library > dependencies. No crash here with psc. So it could be an issue of the drivers. My server is running openSUSE 11.0 (X86-64). > Alan Leo |
From: Alan W. I. <ir...@be...> - 2010-05-25 05:18:51
|
On 2010-05-25 04:54+0100 Leo wrote: > No crash here with psc. So it could be an issue of the drivers. There is an outstanding Mac OS X issue with qt devices that Hazen just discovered which might indicate those devices are not thread safe (at least on that platform). Are all your troubles for qt devices or have you tried other devices which also show errors? For example, it would be worthwhile to check the svg device (a modern PLplot device that does not depend on external libraries at all), and cairo devices assuming you have the pango/cairo library stack (a subset of the GTK+ stack of libraries) installed. Once we get a comprehensive feel for which devices have issues for you and which do not, it might give us a better idea for what to look for (or whether your issue is related to Hazen's). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Leo <sd...@gm...> - 2010-05-25 07:34:48
|
On 2010-05-25 06:18 +0100, Alan W. Irwin wrote: > There is an outstanding Mac OS X issue with qt devices that Hazen just > discovered which might indicate those devices are not thread safe (at least > on that platform). > > Are all your troubles for qt devices or have you tried other devices > which also show errors? The lisp is running on linux. I have no qtwidget on osx yet. I have moved lisp to the remote server because it has more cpus and memory. In my tests in previous posts I usually did them with both xcairo and qtwidget to be absolutely sure. > For example, it would be worthwhile to check the svg device (a modern PLplot > device that does not depend on external libraries at all), and cairo devices > assuming you have the pango/cairo library stack (a subset of the GTK+ stack > of libraries) installed. No crash with svg. > Once we get a comprehensive feel for which devices have issues for you and > which do not, it might give us a better idea for what to look for > (or whether your issue is related to Hazen's). Thanks in advance. > > Alan Leo |
From: Andrew R. <and...@us...> - 2010-05-25 09:54:50
|
On Tue, May 25, 2010 at 08:34:17AM +0100, Leo wrote: > On 2010-05-25 06:18 +0100, Alan W. Irwin wrote: > > There is an outstanding Mac OS X issue with qt devices that Hazen just > > discovered which might indicate those devices are not thread safe (at least > > on that platform). > > > > Are all your troubles for qt devices or have you tried other devices > > which also show errors? > > The lisp is running on linux. I have no qtwidget on osx yet. I have > moved lisp to the remote server because it has more cpus and memory. In > my tests in previous posts I usually did them with both xcairo and > qtwidget to be absolutely sure. > > > For example, it would be worthwhile to check the svg device (a modern PLplot > > device that does not depend on external libraries at all), and cairo devices > > assuming you have the pango/cairo library stack (a subset of the GTK+ stack > > of libraries) installed. > > No crash with svg. > > > Once we get a comprehensive feel for which devices have issues for you and > > which do not, it might give us a better idea for what to look for > > (or whether your issue is related to Hazen's). > > Thanks in advance. So just to be clear, you have only observed the crash with the following interactive devices: xcairo, qtwidget Have you tried xwin on Linux? This has far fewer external dependencies and the thread support for screen refresh is in the driver (so we have more chance of debugging!) You have not observed problems with psc or svg drivers. What about the qt or cairo file based drivers (e.g. pscairo / epsqt)? You might try running with valgrind as an alternative to gdb. It tends to be quite good at finding issues related to memory access / memory allocation. Andrew |