What's test99.pd? Is this a new crash with today's build? .hc
On Apr 3, 2012, at 3:03 PM, John Harrison wrote: > Today's build (April 3, 2012) still crashes with creating/destroying > test99.pd. The gdb reports something a bit different though: > > Program received signal SIGSEGV, Segmentation fault. > 0x0807fd79 in pd_typedmess (x=0x647261, s=0x81c7f68, argc=2, argv=0x825fb80) > at m_class.c:707 > 707 m_class.c: No such file or directory. > in m_class.c > (gdb) watchdog: signaling pd... > > > On Mon, Apr 2, 2012 at 9:53 AM, Hans-Christoph Steiner <h...@at.or.at> wrote: > > On Apr 2, 2012, at 3:32 AM, IOhannes m zmoelnig wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 2012-03-29 19:03, John Harrison wrote: > >> I've been trying to track down a seg fault I keep getting and I'm still > >> not sure if the problem is Gem or Pd-extended or what. > >> > >> This is the latest pd-extended 0.43.1 Beta CVS March 29 (today) running > >> on Oneric 32 but. I have simplified my patch to a point it doesn't make > >> sense anymore but I can still make it crash, so I figure that's what we > >> need. > >> > >> Basically if you create a new patch then make the object [test99 1], > >> then copy and paste that object, then change the 1 parameter to a 2 you > >> get a seg fault most of the time. If not, creating a [test99 3] or > >> [test99 4] should do it, again most of the time. > >> > >> It seems related with Gem but I'm not sure if it is a Gem bug. I tried > >> the same Gem library with Pd vanilla and it didn't crash. On the other > >> hand, it seems related to the [pix_image] object in test99. Also you > >> need to have the parameters to get the patch to crash, even though the > >> patch doesn't take parameters. (The original patch did take parameters.) > >> > >> Core dump has only this information: Program terminated with signal 11, > >> Segmentation fault. > >> #0 0x0111ac01 in gem::RTE::Outlet::send(std::string, > >> std::vector<gem::any, std::allocator<gem::any> >) () from > >> /usr/lib/pd-extended/extra/Gem/Gem.pd_linux > >> > > > > if i'm not mistaken this has been recently fixed in Gem (around 21st of > > march) and is related to threaded loading of images and deleting objects > > while the load is still in process. > > > > to avoid the problem you can do either of those: > > - - upgrade to a new version of gem (there's a backport of the fix to the > > (stable) 0.93 branch of Gem, though no official release has been made > > yet, containing the fix) > > - - avoid using threaded loading of images, e.g by sending the [thread 0( > > message to [pix_image] before loading images. > > - - avoid deleting a [pix_image] that has pending "open" requests > > I just committed the latest patches from the 0.93 Gem branch to the > Pd-extended 0.43 release branch. They'll be in tomorrow's build. John, > could you test this and report back if there are any problems? > > .hc > > ---------------------------------------------------------------------------- > > I hate it when they say, "He gave his life for his country." Nobody gives > their life for anything. We steal the lives of these kids. -Admiral Gene > LeRocque > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > ---------------------------------------------------------------------------- http://at.or.at/hans/
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list