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
[test99] is attached.
-----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
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::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
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
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 hans@at.or.atwrote:
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::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
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
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 hans@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::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
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/
I can't tell if this is a new crash triggered by the same create/destroy event or the old crash. The same scenario triggers the crash (create/destroy test99.pd in a new canvas) but gdb reports something different. This is on today's build, Oneiric 32 bit. test99.pd was attached on this thread and is again attached to this email.
-John
On Tue, Apr 3, 2012 at 2:16 PM, Hans-Christoph Steiner hans@at.or.atwrote:
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 hans@at.or.atwrote:
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::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
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/
On 04/03/12 21:23, John Harrison wrote:
I can't tell if this is a new crash triggered by the same create/destroy event or the old crash. The same scenario triggers the crash (create/destroy test99.pd in a new canvas) but gdb reports something different. This is on today's build, Oneiric 32 bit. test99.pd was attached on this thread and is again attached to this email.
afaict, the new crash is a regression caused by the fix for the first crash.
i have hopefully fixed that as well and committed it to Gem's git (committish 1458b4f8cf in the 0.93 branch, in case somebody wants to backport it)
cvnasdr IOhannes
On Apr 3, 2012, at 4:42 PM, IOhannes m zmölnig wrote:
On 04/03/12 21:23, John Harrison wrote:
I can't tell if this is a new crash triggered by the same create/destroy event or the old crash. The same scenario triggers the crash (create/destroy test99.pd in a new canvas) but gdb reports something different. This is on today's build, Oneiric 32 bit. test99.pd was attached on this thread and is again attached to this email.
afaict, the new crash is a regression caused by the fix for the first crash.
i have hopefully fixed that as well and committed it to Gem's git (committish 1458b4f8cf in the 0.93 branch, in case somebody wants to backport it)
John or IOhannes,
Please let me know when its in the 0.93 branch, and I'll include it in Pd-extended.
.hc
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-04 03:25, Hans-Christoph Steiner wrote:
i have hopefully fixed that as well and committed it to Gem's git (committish 1458b4f8cf in the 0.93 branch, in case somebody wants to backport it)
John or IOhannes,
Please let me know when its in the 0.93 branch, and I'll include it in Pd-extended.
"committed it to Gem's git (committish 1458b4f8cf in the 0.93 branch)"
it would be nice, if john could test it more directly, without having me fix the bug in Gem's master, then backport it to Gem's 0.93, then having hans backport the changes to Pd-extended, then wait for the nightly build and then report that it is not working...
backporting from Gem's master to Gem's 0.93 is fairly trivial using git's cherry-pick. the rest is less fun and should probably only be done once the bug is really fixed.
fmasdr IOhannes
I'll see if I can figure all that out and test this weekend... I assume with git log it will be obvious what commit I need to cherry-pick.
-John
On Wed, Apr 4, 2012 at 2:08 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-04 03:25, Hans-Christoph Steiner wrote:
i have hopefully fixed that as well and committed it to Gem's git
(committish 1458b4f8cf in the 0.93 branch, in case somebody wants to backport it)
John or IOhannes,
Please let me know when its in the 0.93 branch, and I'll include it in
Pd-extended.
"committed it to Gem's git (committish 1458b4f8cf in the 0.93 branch)"
it would be nice, if john could test it more directly, without having me fix the bug in Gem's master, then backport it to Gem's 0.93, then having hans backport the changes to Pd-extended, then wait for the nightly build and then report that it is not working...
backporting from Gem's master to Gem's 0.93 is fairly trivial using git's cherry-pick. the rest is less fun and should probably only be done once the bug is really fixed.
fmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9781EACgkQkX2Xpv6ydvTGPwCfW9oHv5Cwl0YHmUqvnLYjoe7N e0YAoNn2ES0T6jha+hvYXy1IsmxGFZUJ =NZrN -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-04 14:06, John Harrison wrote:
I'll see if I can figure all that out and test this weekend... I assume with git log it will be obvious what commit I need to cherry-pick.
probably i'm a bit too cryptic: Gem's 0.93 git-branch already has the cherry-picked fixes applied. so checkout the 0.93 branch, compile and see whether it has the problem fixed.
fgmasr IOhannes
On Apr 4, 2012, at 8:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-04 14:06, John Harrison wrote:
I'll see if I can figure all that out and test this weekend... I assume with git log it will be obvious what commit I need to cherry-pick.
probably i'm a bit too cryptic: Gem's 0.93 git-branch already has the cherry-picked fixes applied. so checkout the 0.93 branch, compile and see whether it has the problem fixed.
Yes, you were being too cryptic ;) When there is a commit in Gem's 0.93 branch, I'm happy to commit it to the Pd-extended 0.43 release branch. Done:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
John, tomorrow's will include this fix, if you can test it again.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Today's build still fails with same test:
[New Thread 0x1defb70 (LWP 19910)] [New Thread 0x2c86b70 (LWP 19911)]
Program received signal SIGSEGV, Segmentation fault. outlet_anything (x=0x0, s=0x81c7df0, argc=2, argv=0x82181b8) at m_obj.c:469 469 m_obj.c: No such file or directory. in m_obj.c (gdb) watchdog: signaling pd...
On Wed, Apr 4, 2012 at 8:53 AM, Hans-Christoph Steiner hans@at.or.atwrote:
On Apr 4, 2012, at 8:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-04 14:06, John Harrison wrote:
I'll see if I can figure all that out and test this weekend... I assume with git log it will be obvious what commit I need to cherry-pick.
probably i'm a bit too cryptic: Gem's 0.93 git-branch already has the cherry-picked fixes applied. so checkout the 0.93 branch, compile and see whether it has the problem fixed.
Yes, you were being too cryptic ;) When there is a commit in Gem's 0.93 branch, I'm happy to commit it to the Pd-extended 0.43 release branch. Done:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
John, tomorrow's will include this fix, if you can test it again.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.
- retired U.S. Army general, William Odom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-05 17:35, John Harrison wrote:
Today's build still fails with same test:
[New Thread 0x1defb70 (LWP 19910)] [New Thread 0x2c86b70 (LWP 19911)]
Program received signal SIGSEGV, Segmentation fault. outlet_anything (x=0x0, s=0x81c7df0, argc=2, argv=0x82181b8) at m_obj.c:469 469m_obj.c: No such file or directory. in m_obj.c (gdb) watchdog: signaling pd...
please post a complete backtrace (and turn off realtime mode with "-nrt" when running Pd in gdb)
fgmasdr IOhannes
Sorry for the delay on this. I downloaded today's binary build of Pd-extended for Ubuntu 11.10 32 bit, then ran Pd-extended with -nrt in gdb. I still get a segfault when opening/deleting/opening test99.pd as an abstraction. For your convenience, test99.pd is again attached. Here's the backtrace:
Program received signal SIGSEGV, Segmentation fault. outlet_anything (x=0x0, s=0x81c7fc0, argc=2, argv=0x82395d8) at m_obj.c:469 469 m_obj.c: No such file or directory. in m_obj.c (gdb) bt #0 outlet_anything (x=0x0, s=0x81c7fc0, argc=2, argv=0x82395d8) at m_obj.c:469 #1 0x00c4c8dc in gem::RTE::Outlet::send(std::string, std::vector<gem::any, std::allocatorgem::any >) () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux #2 0x00db4443 in pix_image::loaded(unsigned int, imageStruct*, gem::Properties const&) () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux #3 0x00db57b3 in pix_image::loadCallback(void*, unsigned int, imageStruct*, gem::Properties const&) () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux #4 0x00c37f30 in gem::image::PixImageThreadLoader::done(unsigned int, void*) () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux #5 0x00c49996 in gem::thread::SynchedWorkerThread::dequeue() () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux #6 0x00c37bc0 in gem::image::load::poll() () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux #7 0x00db3b6e in pix_image::pix_image(_symbol*) () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux #8 0x00db3ca8 in create_pix_image(_symbol*) () from /usr/lib/pd-extended/extra/Gem/Gem.pd_linux #9 0x0808027a in pd_typedmess (x=0x80ff880, s=0x81cac20, argc=<optimized out>, argv=0xbfffe18c) at m_class.c:795 #10 0x0808631e in binbuf_eval (x=0x824a158, target=0x80ff880, argc=1, argv=0x83bd270) at m_binbuf.c:767
On Thu, Apr 5, 2012 at 12:39 PM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-05 17:35, John Harrison wrote:
Today's build still fails with same test:
[New Thread 0x1defb70 (LWP 19910)] [New Thread 0x2c86b70 (LWP 19911)]
Program received signal SIGSEGV, Segmentation fault. outlet_anything (x=0x0, s=0x81c7df0, argc=2, argv=0x82181b8) at
m_obj.c:469
469m_obj.c: No such file or directory. in m_obj.c (gdb) watchdog: signaling pd...
please post a complete backtrace (and turn off realtime mode with "-nrt" when running Pd in gdb)
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk992LwACgkQkX2Xpv6ydvRcxQCgwF+Sdl5QFz4gKUYxlkvsvI6D fh8AoJbD8XPHJ8au3fnLW+pPjv4VQzwQ =GEzY -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-16 20:44, John Harrison wrote:
Sorry for the delay on this. I downloaded today's binary build of Pd-extended for Ubuntu 11.10 32 bit, then ran Pd-extended with -nrt in
is it possible to build Gem (from the git "master" branch) yourself? what is the exact version it shows for Gem?
fgamsdr IOhannes
On Apr 21, 2012, at 9:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-16 20:44, John Harrison wrote:
Sorry for the delay on this. I downloaded today's binary build of Pd-extended for Ubuntu 11.10 32 bit, then ran Pd-extended with -nrt in
is it possible to build Gem (from the git "master" branch) yourself? what is the exact version it shows for Gem?
Gem in Pd-extended is the 0.93 branch, at commit 1458b4f8cfa12503bba94e2a8804f802f07efdaa
http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/0...
.hc
kill your television
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-21 15:42, Hans-Christoph Steiner wrote:
On Apr 21, 2012, at 9:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-16 20:44, John Harrison wrote:
Sorry for the delay on this. I downloaded today's binary build of Pd-extended for Ubuntu 11.10 32 bit, then ran Pd-extended with -nrt in
is it possible to build Gem (from the git "master" branch) yourself? what is the exact version it shows for Gem?
Gem in Pd-extended is the 0.93 branch, at commit 1458b4f8cfa12503bba94e2a8804f802f07efdaa
thanks hans. however, i was explicitely asking john which version he is using, rather than which version comes bundled with PdX; the two could be different (which i hope, since i really believe that the issue should be fixed, at least in the master branch)
fgamsdr IOhannes
I'm not sure which version of Gem I had with the daily builds of Pd-extended I was downloading. (Is there a way I could figure this out?) The good news is that I built Gem commit a087e24536dcd2e691eef92eafeeef298a4e4274 from git (last commit on Apr 29) and it doesn't crash, so it seems to problem is fixed.
-John
On Sun, Apr 22, 2012 at 4:40 AM, IOhannes m zmoelnig zmoelnig@iem.atwrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-21 15:42, Hans-Christoph Steiner wrote:
On Apr 21, 2012, at 9:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-16 20:44, John Harrison wrote:
Sorry for the delay on this. I downloaded today's binary build of Pd-extended for Ubuntu 11.10 32 bit, then ran Pd-extended with -nrt in
is it possible to build Gem (from the git "master" branch) yourself? what is the exact version it shows for Gem?
Gem in Pd-extended is the 0.93 branch, at commit
1458b4f8cfa12503bba94e2a8804f802f07efdaa
thanks hans. however, i was explicitely asking john which version he is using, rather than which version comes bundled with PdX; the two could be different (which i hope, since i really believe that the issue should be fixed, at least in the master branch)
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+T0f8ACgkQkX2Xpv6ydvSoDgCgodi2d717pTgpzy6uhGiPPxeN /QAAni3FZI7Dm4ol7NvD+gZyJAZmqSQW =6OKP -----END PGP SIGNATURE-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This leads me to the question: are there any more 0.93 releases planned? John's bug and the Mac OS X 1 frame video playback are show stoppers. It seems that Pd-extended should just switch to the git master, hopefully that's not painful.
.hc
On Apr 30, 2012, at 5:22 PM, John Harrison wrote:
I'm not sure which version of Gem I had with the daily builds of Pd-extended I was downloading. (Is there a way I could figure this out?) The good news is that I built Gem commit a087e24536dcd2e691eef92eafeeef298a4e4274 from git (last commit on Apr 29) and it doesn't crash, so it seems to problem is fixed.
-John
On Sun, Apr 22, 2012 at 4:40 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-21 15:42, Hans-Christoph Steiner wrote:
On Apr 21, 2012, at 9:09 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-16 20:44, John Harrison wrote:
Sorry for the delay on this. I downloaded today's binary build of Pd-extended for Ubuntu 11.10 32 bit, then ran Pd-extended with -nrt in
is it possible to build Gem (from the git "master" branch) yourself? what is the exact version it shows for Gem?
Gem in Pd-extended is the 0.93 branch, at commit 1458b4f8cfa12503bba94e2a8804f802f07efdaa
thanks hans. however, i was explicitely asking john which version he is using, rather than which version comes bundled with PdX; the two could be different (which i hope, since i really believe that the issue should be fixed, at least in the master branch)
fgamsdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+T0f8ACgkQkX2Xpv6ydvSoDgCgodi2d717pTgpzy6uhGiPPxeN /QAAni3FZI7Dm4ol7NvD+gZyJAZmqSQW =6OKP -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-30 23:43, Hans-Christoph Steiner wrote:
This leads me to the question: are there any more 0.93 releases planned? John's bug and the Mac OS X 1 frame video playback are show stoppers. It seems that Pd-extended should just switch to the git master, hopefully that's not painful.
yes, i think there will be a 0.93.4 release somewhen pretty soon.
i (still) believe that john's bug can be closed now (whatever the issue with the Pd-extended build might be).
@john: if you don't mind, would you care to check whether the 0.93 branch has the issue fixed as well (current commitish there is 6dedf323d28)? (note: you might need to remove the abstractions/gemdefaultwindow.pd before being able to switch to that branch)
and i don't think that the osx 1 frame video playback is a "show stopper", in a sense that mpg playback on OSx has probably always had this problem and afaict from the bug-report the problem does not appear with other file formats (at least .mov)
madsr IOhannes
On May 2, 2012, at 2:47 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-30 23:43, Hans-Christoph Steiner wrote:
This leads me to the question: are there any more 0.93 releases planned? John's bug and the Mac OS X 1 frame video playback are show stoppers. It seems that Pd-extended should just switch to the git master, hopefully that's not painful.
yes, i think there will be a 0.93.4 release somewhen pretty soon.
Ok, I'll keep Pd-extended's Gem using the 0.93 branch then.
i (still) believe that john's bug can be closed now (whatever the issue with the Pd-extended build might be).
@john: if you don't mind, would you care to check whether the 0.93 branch has the issue fixed as well (current commitish there is 6dedf323d28)? (note: you might need to remove the abstractions/gemdefaultwindow.pd before being able to switch to that branch)
Pd-extended's Gem was up-to-date to the Gem 0.93 branch, except for the most recent three commits, which don't seem related to John's bug:
- open shader files as binary
- open shader files as binary (part2)
- help patch for [trapezoid]
I just committed those three. So Pd-extended builds can be used to test this as well.
and i don't think that the osx 1 frame video playback is a "show stopper", in a sense that mpg playback on OSx has probably always had this problem and afaict from the bug-report the problem does not appear with other file formats (at least .mov)
This bug is most definitely a new bug that does not affect Pd-extended 0.42.5 at all. The videos also play fine in Quicktime and in Pd-extended 0.42.5.
.hc
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
John Harrison -
John Harrison