-----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::allocatorgem::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
ghsdr IOhannes