I am not sure if you already mentioned this but did you actually try recompiling gridflow from scratch or are you using one of the precompiled packages in conjunction with the l2ork pd-extended?
ALAN BROOKER <alan.brooker2...@gmail.com> wrote: >If I press ctrl+1 to create an object that's when it crashes out, opening pd >patches is fine but if I try to edit them then a crash will occur as well. >Also opening Grdiflow help index causes crashes without loading the index >patch at all > >On Sat, Nov 27, 2010 at 5:43 PM, Ivica Ico Bukvic <i...@vt.edu> wrote: > >> This looks like an incompatibility between tagged moving of an object and >> something in the gridflow. >> >> Does this occur with any object or just some specific object(s)? >> >> Mathieu, The offending call should be the same like the Regular call except >> that is this place is using a tag. It can be found in the g_text.c file. >> >> Cheers! >> >> ALAN BROOKER <alan.brooker2...@gmail.com> wrote: >> >> >Hi Mathieu, >> > >> >Thanks for this, I have done a trace back with the following output on the >> >terminal : >> > >> >(gdb) run >> >Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd >> >[Thread debugging using libthread_db enabled] >> >[New Thread 0xb6168b70 (LWP 5214)] >> ><init> : Avifile RELEASE-0.7.48-100119-21:44-../src/configure >> ><init> : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr >> >pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext >> >fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc >> extd_api >> ><init> : 3200.00 MHz AMD Phenom(tm) II X2 555 Processor detected >> >where >> > >> >Program received signal SIGSEGV, Segmentation fault. >> >0x00000011 in ?? () >> >(gdb) where >> >#0 0x00000011 in ?? () >> >#1 0x080a9665 in gobj_displace_withtag (x=0x8215790, >> > dx=<value optimised out>, dy=0) at g_editor.c:70 >> >#2 canvas_displaceselection (x=0x8215790, dx=<value optimised out>, dy=0) >> > at g_editor.c:1913 >> >#3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) >> > at g_editor.c:2102 >> >#4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, >> > argv=0xbffff08c) at m_class.c:792 >> >#5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, >> > argv=0xbffff08c) at m_class.c:813 >> >#6 0x080cff0a in binbuf_eval (x=0x814d610, target=<value optimised out>, >> > argc=0, argv=0x0) at m_binbuf.c:726 >> >#7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 >> >#8 0x080ddb7a in sys_domicrosleep (microsec=<value optimised out>, >> > pollem=<value optimised out>) at s_inter.c:198 >> >#9 0x080de662 in sys_pollgui () at s_inter.c:862 >> >#10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 >> >#11 m_mainloop () at m_sched.c:560 >> >#12 0x080dcc09 in sys_main (argc=5, argv=0xbffff4e4) at s_main.c:310 >> >#13 0x080e56cb in main (argc=5, argv=0xbffff4e4) at s_entry.c:32 >> >(gdb) where >> >#0 0x00000011 in ?? () >> >#1 0x080a9665 in gobj_displace_withtag (x=0x8215790, >> > dx=<value optimised out>, dy=0) at g_editor.c:70 >> >#2 canvas_displaceselection (x=0x8215790, dx=<value optimised out>, dy=0) >> > at g_editor.c:1913 >> >#3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) >> > at g_editor.c:2102 >> >#4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, >> > argv=0xbffff08c) at m_class.c:792 >> >#5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, >> > argv=0xbffff08c) at m_class.c:813 >> >#6 0x080cff0a in binbuf_eval (x=0x814d610, target=<value optimised out>, >> > argc=0, argv=0x0) at m_binbuf.c:726 >> >#7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 >> >#8 0x080ddb7a in sys_domicrosleep (microsec=<value optimised out>, >> > pollem=<value optimised out>) at s_inter.c:198 >> >#9 0x080de662 in sys_pollgui () at s_inter.c:862 >> >#10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 >> >#11 m_mainloop () at m_sched.c:560 >> >#12 0x080dcc09 in sys_main (argc=5, argv=0xbffff4e4) at s_main.c:310 >> >#13 0x080e56cb in main (argc=5, argv=0xbffff4e4) at s_entry.c:32 >> > >> >Thanks again >> > >> >Al >> >On Sat, Nov 27, 2010 at 11:37 AM, Mathieu Bouchard <ma...@artengine.ca >> >wrote: >> > >> >> On Sat, 27 Nov 2010, ALAN BROOKER wrote: >> >> >> >> Also Gridflow as mentioned previously causes crashes but not so hard as >> >>> py. When I swapped the L2Orkt file to normal extended, I could use >> Gridflow >> >>> in the new gui as normal- so perhaps the issue is not in the tk file >> but >> >>> else where? >> >>> >> >> >> >> If you (or someone else) can narrow down the l2ork<->gridflow problems, >> I >> >> could try to fix them. >> >> >> >> Is it something happening mostly with the helpfiles, or also with >> something >> >> else ? Is it happening at startup, or later ? >> >> >> >> What is the "L20rkt file" ? >> >> >> >> _______________________________________________________________________ >> >> | Mathieu Bouchard ------------------------------------- Aix-en-Provence >> > >> >_______________________________________________ >> >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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
