Hi,
as I'm a Gem dork, I don't know, at all, why the Trigger Gang Bang patch keeps crashing at always the same position (after the first 16 bars.) I can however provide a backtrace, maybe this can be a hint:
wt?!: and hop
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076242848 (LWP 20958)] 0x4019c44c in mallopt () from /lib/tls/libc.so.6 (gdb) bt #0 0x4019c44c in mallopt () from /lib/tls/libc.so.6 #1 0x0809b55b in atom_string (a=0x4025eedc, buf=0x2f102f0 <Address 0x2f102f0 out of bounds>, bufsize=1162937064) at m_atom.c:83 #2 0x4050715f in TextBase::textMess () from /usr/lib/pd/extra/Gem.pd_linux #3 0x405072d0 in TextBase::textMessCallback () from /usr/lib/pd/extra/Gem.pd_linux #4 0x08099477 in pd_typedmess (x=0x824fae0, s=0x425ffff8, argc=1, argv=0x80ee5b0) at m_class.c:656 #5 0x0809aac7 in outlet_anything (x=0x2f102f1, s=0x81fd750, argc=1, argv=0x80ee5b0) at m_obj.c:385 #6 0x080990c6 in pd_typedmess (x=0x824f704, s=0x425ffff8, argc=1, argv=0x80ee5b0) at m_class.c:740 #7 0x0809c654 in binbuf_eval (x=0x48, target=0x824f704, argc=0, argv=0x0) at m_binbuf.c:578 #8 0x08060ab5 in message_bang (x=0x48) at g_text.c:294 #9 0x0809853f in pd_bang (x=0x48) at m_pd.c:269 #10 0x0809a88b in outlet_bang (x=0x2f102f1) at m_obj.c:323 #11 0x0809861a in bindlist_bang (x=0x48) at m_pd.c:269 #12 0x080994f7 in pd_typedmess (x=0x828bb38, s=0x425ffff8, argc=0, argv=0x80ee5a8) at m_class.c:632 #13 0x0809c654 in binbuf_eval (x=0x48, target=0x828bb38, argc=0, argv=0x0) at m_binbuf.c:578 #14 0x08060ab5 in message_bang (x=0x48) at g_text.c:294 #15 0x0809853f in pd_bang (x=0x48) at m_pd.c:269 #16 0x0809a88b in outlet_bang (x=0x2f102f1) at m_obj.c:323 #17 0x0809853f in pd_bang (x=0x48) at m_pd.c:269 #18 0x0809853f in pd_bang (x=0x48) at m_pd.c:269 #19 0x0809a88b in outlet_bang (x=0x2f102f1) at m_obj.c:323 #20 0x08098567 in pd_float (x=0x48, f=3.54134556e-37) at m_pd.c:274 #21 0x0809a96f in outlet_float (x=0x2f102f1, f=384) at m_obj.c:355 #22 0x0809865e in bindlist_float (x=0x48, f=384) at m_pd.c:274 #23 0x08098567 in pd_float (x=0x48, f=3.54134556e-37) at m_pd.c:274 #24 0x08098567 in pd_float (x=0x48, f=3.54134556e-37) at m_pd.c:274 #25 0x0809a96f in outlet_float (x=0x2f102f1, f=384) at m_obj.c:355 #26 0x080c9153 in pdint_bang (x=0x2f102f1) at x_connective.c:33 #27 0x0809853f in pd_bang (x=0x48) at m_pd.c:269 #28 0x0809a88b in outlet_bang (x=0x2f102f1) at m_obj.c:323 #29 0x080a1066 in m_scheduler () at m_sched.c:357 #30 0x080a40af in sys_main (argc=72, argv=0x81f4838) at s_main.c:263 #31 0x080a78eb in main (argc=72, argv=0x48) at s_entry.c:49 (gdb)
Any ideas what might cause this? It is using the Debian package of Gem-0.90 and Pd 0.37
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hi,
as I'm a Gem dork, I don't know, at all, why the Trigger Gang Bang patch keeps crashing at always the same position (after the first 16 bars.) I can however provide a backtrace, maybe this can be a hint:
Any ideas what might cause this? It is using the Debian package of Gem-0.90 and Pd 0.37
i have tested it and it works perfectly with my self-compiled pd/gem (0.37-4; 0.90cvs) until it "segfaults...again" (i like this most)
however, it is true that the debian-packaged Gem crashes as soon as the _intro-text should be displayed.
i noticed that the debian-package has no font-support (Günther ?)
the crash is definitely a Gem bug (i admit that i have not thoroughly tested the stability of Gem without any of the supported text-rendering libs)
mfg.as.dr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
i have tested it and it works perfectly with my self-compiled pd/gem (0.37-4; 0.90cvs) until it "segfaults...again" (i like this most)
Ah, I now built the official sources and indeed it works now, although the part with the fonts is REAAAALLLLYYYY slow on my machine (Matrox G450, Athlon 900MHz). Beautiful work Amyeric. Ich liebe dich!!
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Ah, I now built the official sources and indeed it works now, although the part with the fonts is REAAAALLLLYYYY slow on my machine (Matrox G450, Athlon 900MHz).
I really wonder, why font renderin is so slow. Is it, that Gem has to generate a whole lot of polygons for this?
Ciao
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Ah, I now built the official sources and indeed it works now, although the part with the fonts is REAAAALLLLYYYY slow on my machine (Matrox G450, Athlon 900MHz).
I really wonder, why font renderin is so slow. Is it, that Gem has to generate a whole lot of polygons for this?
actually FTGL uses display-lists for each glyph. (which should be quite fast unless a) it is done in software ;-) and/or b) the glyph-parsing of the text-string is slow...) i don't know right know, how it is done with GLTT.
with which font-renderer is your version of Gem compiled with ? (it should give you a message when the first text-related object is created)
mfg.a.sdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
I really wonder, why font renderin is so slow. Is it, that Gem has to generate a whole lot of polygons for this?
actually FTGL uses display-lists for each glyph. (which should be quite fast unless a) it is done in software ;-) and/or b) the glyph-parsing of the text-string is slow...) i don't know right know, how it is done with GLTT.
with which font-renderer is your version of Gem compiled with ? (it should give you a message when the first text-related object is created)
GEM: Graphics Environment for Multimedia GEM: ver: 0.90 GEM: compiled: Sep 7 2004 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version on irix/windows) GEM: Chris Clepper (macOS-X) GEM: Daniel Heckenberg (windows) GEM: James Tittle (macOS-X) GEM: IOhannes m zmoelnig (linux/windows) Gem has been compiled with FTGL ! ... GEM: loaded images: /home/freak/big/audio/pd/dev/compo/demo/m/pin .jpg from 0 to 1 skipping 1 GEM: Only using 8 color bits Direct Rendering enabled! GEM: Start rendering
So it is using FTGL, but maybe FTGL on Debian isn't using Direct Rendering? I'll have to check this ...
Ciao
Frank Barknecht _ ______footils.org__
On Sep 7, 2004, at 6:03 AM, IOhannes m zmoelnig wrote:
the crash is definitely a Gem bug (i admit that i have not thoroughly tested the stability of Gem without any of the supported text-rendering libs)
...the first time i ran it, it was missing arial.ttf in the "m" directory, so i just copied it from my gem install...then it ran but quit after the initial text display (not sure if there was an error message): it wasn't until I ran it a third time that I got to see the whole thing! And wow, it's incredible! I was originally thinking of doing my talk on "recapitulating demoscene graphics in GEM" ;-)
...very inspiring, now to go work on my entry...
james
Hallo, James Tittle II hat gesagt: // James Tittle II wrote:
...the first time i ran it, it was missing arial.ttf in the "m" directory, so i just copied it from my gem install.
I got this, too. I wonder, if it is possible to specify the arial.ttf in the Gem-data directory in a platform-independent way?
...very inspiring, now to go work on my entry...
Yeah, please do so!!
Ciao
Frank Barknecht _ ______footils.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
as I'm a Gem dork, I don't know, at all, why the Trigger Gang Bang patch keeps crashing at always the same position (after the first 16 bars.) I can however provide a backtrace, maybe this can be a hint:
BTW: The crash happens, when the receiver "go2" is getting a bang, while the Gem window is active.
Ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
IOhannes m zmoelnig -
James Tittle II