[PD] Gridflow+ L2Ork pd-extended (was: L2Ork pd-extended release candidate 1 now available)

[ALAN BROOKER]

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 <ico at 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.brooker2010 at 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 at 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 at iem.at mailing list
> >UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101127/ed55efb6/attachment.htm>