Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
hmm, this weekend i helped someone out to setup Gem on an intl gfx chip and lo and behold! it did not crash. at least Gem claimed that it had "DRI enabled".
That's good news! I'll see if I can confirm this for my trusty Matrox machine, which isn't yet updated to the newest Gem.
Nope, still segfaults with a fresh cvs build:
$ gdb --args /usr/bin/pd -lib ./Gem
<make gemwin, destroy it, crash>
(gdb) bt #0 0xb5481af0 in ?? () #1 0xb792bd1c in glXDestroyContext () from /usr/lib/libGL.so.1 #2 0xb792de40 in glXMakeCurrentReadSGI () from /usr/lib/libGL.so.1 #3 0xb792e0d3 in glXMakeCurrent () from /usr/lib/libGL.so.1 #4 0xb7b6f2d2 in gemWinMakeCurrent () from ./Gem.pd_linux #5 0xb7b5e55a in GemMan::destroyWindow () from ./Gem.pd_linux #6 0xb7b5f125 in GemMan::render () from ./Gem.pd_linux #7 0x080b4803 in sched_tick (next_sys_time=86200320) at m_sched.c:372 #8 0x080b58d2 in m_mainloop () at m_sched.c:482 #9 0x080b8b2b in sys_main (argc=3, argv=0xbf8a5b54) at s_main.c:307 #10 0x080c1c8f in main (argc=Cannot access memory at address 0x0 ) at s_entry.c:32
It behaves slightly different when using single context Gem. Here I can destroy the gemwin once, but creating it again gives this backtrace:
$ GEM_SINGLE_CONTEXT=1 gdb --args /usr/bin/pd -lib ./Gem
<make gemwin, destroy it, nocrash, "create, 1" gemwin again, crash>
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210935616 (LWP 10999)] 0xb54d5cea in ?? () (gdb) bt #0 0xb54d5cea in ?? () #1 0xb7938774 in __glXInitialize () from /usr/lib/libGL.so.1 #2 0xb79340ad in glXQueryVersion () from /usr/lib/libGL.so.1 #3 0xb7935dda in glXChooseVisual () from /usr/lib/libGL.so.1 #4 0xb7b7a75f in createGemWindow () from ./Gem.pd_linux #5 0xb7b6af2c in GemMan::createWindow () from ./Gem.pd_linux #6 0xb7b99dce in gemwin::createMess () from ./Gem.pd_linux #7 0xb7b9a7a7 in gemwin::createMessCallback () from ./Gem.pd_linux #8 0x080a93b4 in pd_typedmess (x=0x82db620, s=0x824e2a8, argc=0, argv=0xbfab036c) at m_class.c:730 #9 0x080ac047 in outlet_anything (x=0x82db6a8, s=0x824e2a8, argc=0, argv=0xbfab036c) at m_obj.c:390 #10 0x080a8fe2 in pd_typedmess (x=0x82db694, s=0x824e2a8, argc=0, argv=0xbfab036c) at m_class.c:749 #11 0x080adc0e in binbuf_eval (x=0x8237e90, target=Variable "target" is not available. ) at m_binbuf.c:722 #12 0x0805f8fd in message_click (x=0x82db678, xpos=188, ypos=137, shift=0, ctrl=0, alt=0) at g_text.c:303 #13 0x08063c21 in text_click (z=0x82db678, glist=0x823e360, xpix=188, ypix=137, shift=0, alt=0, dbl=0, doit=1) at g_text.c:1073 #14 0x0808ac23 in canvas_doclick (x=0x823e360, xpos=188, ypos=137, which=1, mod=0, doit=1) at g_editor.c:92 #15 0x0808bc3b in canvas_mousedown (x=0x823e360, xpos=188, ypos=137, which=1, mod=0) at g_editor.c:1253 #16 0x080a9375 in pd_typedmess (x=0x823e360, s=0x822bc40, argc=4, argv=0xbfab06bc) at m_class.c:728 #17 0x080a8fe2 in pd_typedmess (x=0x82db4c0, s=0x822bc40, argc=4, argv=0xbfab06bc) at m_class.c:749 #18 0x080adc0e in binbuf_eval (x=0x82383d8, target=Variable "target" is not available. ) at m_binbuf.c:722 #19 0x080bbb65 in socketreceiver_read (x=0x8237ed8, fd=7) at s_inter.c:546 #20 0x080b8fd8 in sys_domicrosleep (microsec=Variable "microsec" is not available. ) at s_inter.c:184 #21 0x080ba007 in sys_pollgui () at s_inter.c:833 #22 0x080b5671 in m_mainloop () at m_sched.c:488 #23 0x080b8b2b in sys_main (argc=3, argv=0xbfab1f54) at s_main.c:307 #24 0x080c1c8f in main (argc=216, argv=0x82dcbf0) at s_entry.c:32
The second backtrace looks different from what I'm used to. I cannot really read it: Is it a crash in Gem or in Pd? And what are the (dis)advantages of running with single context?
This is on Debian stable with: ii libgl1-mesa-glx 6.5.1-0.5
pd MAIN from CVS, and a Matrox G450 (old but gold).
I will try the Intel laptop running Debian testing later.
Ciao
Frank Barknecht _ ______footils.org__