frankiefoo Posted July 17, 2012 at 10:43 PM Share Posted July 17, 2012 at 10:43 PM Hallo zusammen, ich habe den Brick Viewer auf verschiedenen Maschinen getestet, davon 3 verschiedene 64-Bit Maschinen (Ubuntu, Mac) sowie auf meinem ThinkPad X60s, 32-Bit. Auf letzterem erhalte ich auf Ubuntu wie auch unter Debian 6 (Squeeze) einen Segmentation Fault, sobald ich mit dem IMU Brick verbinden will. Mit dem Master-Brick sowie dem Servo-Brick habe ich keine Probleme. Ich habe die kompilierte Version von brickv sowie eine selbst kompilierte Version getestet. Meine Vermutung ist, dass das IMU-Brick bei 32-Bit Maschinen Probleme macht. Ist das Problem bekannt? Viele Grüsse, Frank Quote Link to comment Share on other sites More sharing options...
borg Posted July 18, 2012 at 07:02 AM Share Posted July 18, 2012 at 07:02 AM Also bei mir gibt es keine Probleme mit meinem Thinkpad X41 mit der IMU. Kannst du das unter Debian mal mit strace starten und gucken ob irgendein sinnvoller Hinweis dabei rumkommt? Quote Link to comment Share on other sites More sharing options...
frankiefoo Posted July 28, 2012 at 05:05 PM Author Share Posted July 28, 2012 at 05:05 PM Hi borg, strace gibt folgenden Output: [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0, NULL) = 2314 --- SIGCHLD (Child exited) @ 0 (0) --- write(2, "Segmentation fault\n", 19Segmentation fault ) = 19 read(10, "", 8192) = 0 exit_group(139) = ? Hilft das? Gruss! Quote Link to comment Share on other sites More sharing options...
borg Posted July 29, 2012 at 08:09 PM Share Posted July 29, 2012 at 08:09 PM Mhh, nicht wirklich. Ich bin ein wenig ratlos. Hat irgendwer eine Idee? Quote Link to comment Share on other sites More sharing options...
AuronX Posted July 29, 2012 at 09:52 PM Share Posted July 29, 2012 at 09:52 PM Was passiert beim IMU anderes als bei den anderen Bricks? Rendert ihr das Teil nicht in 3D, wegen der Rotation? Ich würde vermuten, dass irgendeine Lib abschmiert... oder kann man in python (ohne C-Zugabe) ohne weiteres Seg-Faults provozieren? Ich würde versuchen zu überlegen was das IMU im Viewer vom Rest unterscheidet, mir fällt (nur aus Screenshotwissen) als einziges ein, dass dort villt andere Grafikfunktionen genutzt werden könnten. Quote Link to comment Share on other sites More sharing options...
borg Posted July 29, 2012 at 10:05 PM Share Posted July 29, 2012 at 10:05 PM Das IMU Plugin vom Brick Viewer benutzt OpenGL, das ist der einzige Unterschied der mir zu anderen Bricks/Bricklets einfällt. Quote Link to comment Share on other sites More sharing options...
AuronX Posted July 30, 2012 at 09:25 AM Share Posted July 30, 2012 at 09:25 AM Klingt für mich nach einem guten Kandidaten... @frankie: laufen auf dem gerät andere OpenGL-Anwendungen? @borg: kriegst du eine brickv-version ohne OpenGL-Abhängigkeit zusammengehackt? Auf diese Weise könnte man sicherstellen, dass es daran liegt... Quote Link to comment Share on other sites More sharing options...
photron Posted July 30, 2012 at 09:30 AM Share Posted July 30, 2012 at 09:30 AM frankiefoo, kannst du brickv mal in gdb starten um zum segfault einen Backtrace zubekommen? Dann können wir sehen was ihn verursacht und stochern hier nicht länger im Trüben. Quote Link to comment Share on other sites More sharing options...
frankiefoo Posted March 11, 2013 at 09:00 PM Author Share Posted March 11, 2013 at 09:00 PM So leute, sorry für die lange Funkstille... Erst mal vielen Dank für die Hinweise. Ich habe endlich mein IMU mit gdb gedebugged und folgenden Output erhalten: Program received signal SIGSEGV, Segmentation fault. 0xb269c5e6 in glClearColor () from /usr/lib/libGL.so.1 (gdb) backtrace #0 0xb269c5e6 in glClearColor () from /usr/lib/libGL.so.1 #1 0xb52ca7df in ffi_call_SYSV () from /usr/lib/python2.6/lib-dynload/_ctypes.so #2 0xb52ca61e in ffi_call () from /usr/lib/python2.6/lib-dynload/_ctypes.so #3 0xb52c527d in _CallProc () from /usr/lib/python2.6/lib-dynload/_ctypes.so #4 0xb52bcd7e in ?? () from /usr/lib/python2.6/lib-dynload/_ctypes.so #5 0x0806232a in PyObject_Call () #6 0x080df7b1 in PyEval_EvalFrameEx () #7 0x080e18b0 in PyEval_EvalFrameEx () #8 0x080e2507 in PyEval_EvalCodeEx () #9 0x0816b80c in ?? () #10 0x0806232a in PyObject_Call () #11 0x0806a311 in ?? () #12 0x0806232a in PyObject_Call () #13 0x080b50c4 in ?? () #14 0x080acd65 in ?? () #15 0x0806232a in PyObject_Call () #16 0x080e016b in PyEval_EvalFrameEx () #17 0x080e2507 in PyEval_EvalCodeEx () #18 0x0816b80c in ?? () #19 0x0806232a in PyObject_Call () #20 0x0806a311 in ?? () #21 0x0806232a in PyObject_Call () #22 0x080b50c4 in ?? () #23 0x080acd65 in ?? () #24 0x0806232a in PyObject_Call () #25 0x080e016b in PyEval_EvalFrameEx () #26 0x080e18b0 in PyEval_EvalFrameEx () #27 0x080e2507 in PyEval_EvalCodeEx () #28 0x0816b80c in ?? () #29 0x0806232a in PyObject_Call () #30 0x0806a311 in ?? () #31 0x0806232a in PyObject_Call () #32 0x080db582 in PyEval_CallObjectWithKeywords () #33 0xb624f337 in sip_api_invoke_slot () from /usr/lib/pymodules/python2.6/sip.so #34 0xb61a5783 in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so #35 0xb61a587e in ?? () from /usr/lib/pymodules/python2.6/PyQt4/QtCore.so Die Vermutung, dass OpenGL dahiner steckt, ist also genau richtig. Ich verwende Debian Squeeze auf einem ThinkPad X60s. Grafikkarte ist Intel Onboard, die leider standardmässig auf Debian nur mit OpenGL 1.4 betrieben wird. Hat jemand eine Idee, was hier zu tun ist? Quote Link to comment Share on other sites More sharing options...
photron Posted March 12, 2013 at 09:22 AM Share Posted March 12, 2013 at 09:22 AM Okay, es geht also in OpenGL kaputt. Funktionieren den andere OpenGL Programme, wie z.B. das OpenGL Testprogramm glxgears? Quote Link to comment Share on other sites More sharing options...
frankiefoo Posted March 13, 2013 at 07:02 PM Author Share Posted March 13, 2013 at 07:02 PM Ja, glxgears läuft. Ich verwende das IMU mittlerweile auch schon in einem eigenen C++ Projekt zusammen mit OpenGL. Das Problem liegt also an brickv. Liegt es vielleicht an meiner alten OpenGL Version 1.4? Quote Link to comment Share on other sites More sharing options...
photron Posted March 14, 2013 at 09:02 AM Share Posted March 14, 2013 at 09:02 AM Ich habe da eine Vermutung. Kannst du folgendes testen? In /usr/share/brickv/plugin_system/plugins/imu/imu_gl_widget.py die Zeile mit self.initializeGL() auskommentieren oder entfernen. Das ist ca. in Zeile 59. Dieser Aufruf ist nicht notwendig, sollte aber eigentlich kein Problem machen. Es kann aber sein, dass in deinem Fall zu dem Zeitpunkt kein OpenGL Kontext aktiv ist und der glClearColor Aufruf in initializeGL das nicht verträgt. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.