Running GEM on eee (1 gb) crashes Pd whenever i destroy a gemwin. Terminal reports Segmentation fault. any tips? any flags that will make GEM behave better?
thanks
potax flan wrote:
Running GEM on eee (1 gb) crashes Pd whenever i destroy a gemwin. Terminal reports Segmentation fault. any tips? any flags that will make GEM behave better?
read through the console output when creating/destroying the gemwindow for hints (use "-stderr -verbose").
try setting the environmental variable GEM_SINGLE_CONTEXT to "1" before starting pd/Gem and tell us what happens.
mfga.sdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
potax flan wrote:
Running GEM on eee (1 gb) crashes Pd whenever i destroy a gemwin. Terminal reports Segmentation fault. any tips? any flags that will make GEM behave better?
read through the console output when creating/destroying the gemwindow for hints (use "-stderr -verbose").
try setting the environmental variable GEM_SINGLE_CONTEXT to "1" before starting pd/Gem and tell us what happens.
The Eee PC has an Intel gfx chipset, so I suppose it's the longstanding bug with Gem crashing Pd in the GL context switch (or something like that). It happens with all open source Mesa drivers like those for ati, intel or matrox cards. The only workaround I know: Don't close the gemwin.
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
potax flan wrote:
Running GEM on eee (1 gb) crashes Pd whenever i destroy a gemwin. Terminal reports Segmentation fault. any tips? any flags that will make GEM behave better?
read through the console output when creating/destroying the gemwindow for hints (use "-stderr -verbose").
try setting the environmental variable GEM_SINGLE_CONTEXT to "1" before starting pd/Gem and tell us what happens.
The Eee PC has an Intel gfx chipset, so I suppose it's the longstanding bug with Gem crashing Pd in the GL context switch (or something like that). It happens with all open source Mesa drivers like those for ati, intel or matrox cards. The only workaround I know: Don't close the gemwin.
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".
probably a special chip that works :-) (he was using ubuntu hoary and once i convinced him to not try to install the official "Pd-extended-0.39" which has loads of unmet dependencies but rather the 0.40-rc, everything worked out of the box)
fgmasdr IOhannes
Hallo, 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.
Ciao
Frank Barknecht _ ______footils.org__
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__
If you're using the fglrx driver & X11 is crashing on opening GEM patches, you need to set the environmental variable of GEM_SINGLE_CONTEXT=1 by adding the following to your ~/.bashrc or /etc/profile: export GEM_SINGLE_CONTEXT=1 -> http://puredata.info/docs/faq/fix-for-gem-crashing-x11-when-using-fglrx salutis olsen
On Tue, Jul 1, 2008 at 5:53 PM, potax flan potaxpotax@gmail.com wrote:
try setting the environmental variable GEM_SINGLE_CONTEXT to "1" before starting pd/Gem and tell us what happens.
where do i set that variable? thanks
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
potax flan wrote:
try setting the environmental variable GEM_SINGLE_CONTEXT to "1" before starting pd/Gem and tell us what happens.where do i set that variable?
in your environment :-)
that is the console you start Pd from (preferrably, when testing) or you can also set it system wide (once you know it works)
http://gem.iem.at/documentation/faq/gemwincrashfglrx
and it's duplicate: http://puredata.info/docs/faq/fix-for-gem-crashing-x11-when-using-fglrx
fgmasdr IOhannes
just installed debian lenny on the eeePC and gem works fine. just ran a few basic tests but i get NO segmentation faults when destroying gemwins. just thought i'd share this. p
On Thu, Jul 3, 2008 at 12:38 AM, potax flan potaxpotax@gmail.com wrote:
try setting the environmental variable GEM_SINGLE_CONTEXT to "1"
before starting pd/Gem and tell us what happens.
still crashes and reports:
GEM: stop rendering socket receive error: connection reset by peer (104) Segmentation fault
potax flan wrote:
just installed debian lenny on the eeePC and gem works fine. just ran a few basic tests but i get NO segmentation faults when destroying gemwins. just thought i'd share this.
that's good news and thanks for sharing.
which eee do you have (not that the chipsets differ so much...)?
fga,mr IOhannes
hi list,
just got a 901 and gem seems to run fine so far, i'd like to know how
to access the webcam though in GEM.
(ubuntu is on it)
Am 28.07.2008 um 17:46 schrieb IOhannes m zmoelnig:
potax flan wrote:
just installed debian lenny on the eeePC and gem works fine. just
ran a few basic tests but i get NO segmentation faults when destroying gemwins. just thought i'd share this.that's good news and thanks for sharing.
which eee do you have (not that the chipsets differ so much...)?
fga,mr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Interesting,
I booted puredyne (miso) on my eee 900 and it crashes on destroy (which is what I expected due to the intel chip). This is odd since its based on lenny.
What version of DRI/Mesa/GLX are you using in lenny? (So I can compare with miso)
B. Bogart
potax flan wrote:
just installed debian lenny on the eeePC and gem works fine. just ran a few basic tests but i get NO segmentation faults when destroying gemwins. just thought i'd share this. p
On Thu, Jul 3, 2008 at 12:38 AM, potax flan <potaxpotax@gmail.com mailto:potaxpotax@gmail.com> wrote:
try setting the environmental variable GEM_SINGLE_CONTEXT to "1" before starting pd/Gem and tell us what happens. still crashes and reports: GEM: stop rendering socket receive error: connection reset by peer (104) Segmentation fault
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
FWIW, I got one and installed the latest extended on top of the existing Xandros - GEM segfaults on closing a window with that too.
a.
On Tue, 12 Aug 2008 08:49:07 -0700 "B. Bogart" ben@ekran.org wrote:
Interesting,
I booted puredyne (miso) on my eee 900 and it crashes on destroy (which is what I expected due to the intel chip). This is odd since its based on lenny.
What version of DRI/Mesa/GLX are you using in lenny? (So I can compare with miso)
B. Bogart
potax flan wrote:
just installed debian lenny on the eeePC and gem works fine. just ran a few basic tests but i get NO segmentation faults when destroying gemwins. just thought i'd share this. p
On Thu, Jul 3, 2008 at 12:38 AM, potax flan <potaxpotax@gmail.com mailto:potaxpotax@gmail.com> wrote:
try setting the environmental variable GEM_SINGLE_CONTEXT to "1" before starting pd/Gem and tell us what happens. still crashes and reports: GEM: stop rendering socket receive error: connection reset by peer (104) Segmentation fault
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Andy Farnell -
B. Bogart -
Frank Barknecht -
IOhannes m zmoelnig -
Max Neupert -
olsen wolf -
potax flan