Segmentation Fault

[frankiefoo]

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

 

 

 

[borg]

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?

[frankiefoo]

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!

[borg]

Mhh, nicht wirklich. Ich bin ein wenig ratlos. Hat irgendwer eine Idee?

[AuronX]

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.

[borg]

Das IMU Plugin vom Brick Viewer benutzt OpenGL, das ist der einzige Unterschied der mir zu anderen Bricks/Bricklets einfällt.

[AuronX]

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...

[photron]

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.

[frankiefoo]

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?

[photron]

Okay, es geht also in OpenGL kaputt.

 

Funktionieren den andere OpenGL Programme, wie z.B. das OpenGL Testprogramm glxgears?

[frankiefoo]

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?

 

[photron]

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.