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.brooker2010@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 matju@artengine.cawrote:
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
On Sat, 27 Nov 2010, Ivica Ico Bukvic 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.
Did you say you expanded t_widgetbehavior ? That sounds like that could be the problem. GridFlow compiles with a bundled m_pd.h that does not include extra fields there. Then it hacks the comment-class to add an inlet to it and keep it properly hidden, and this requires copying the t_widgetbehavior struct of the comment-class.
Given that I want a single binary for all distributions of Pd, and that I really need the comment-inlets feature, I'll have to add an extra «hack» for that. How do I check for your version of Pd ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC