Pd-dev July 2012

pd-dev@lists.iem.at

11 participants
16 discussions

pd fails to boot with init.d
by Duncan Speakman 19 Jul '12

19 Jul '12

[ cross posting from the pd-list - apologies ] I have made an init.d script to start and stop pd. This works fine in an ssh console. However when the script is invoked by the runlevel startup sequence ie rc5.d/S99puredata, pd complains thus: pd: error while loading shared libraries: libjack.so.0: cannot open shared object file: No such file or directory This is peculiar as I'm using alsa and jack isn't installed. I have verified that the alsa devices have initialised before pd is loade. Why is pd looking for jack and failing to open? Is there something weird about using alsa from an rc script rather than the user console?" Running Ubuntu 12.04 - armhf thanks for any thoughts! -- follow me : @_dspk

1 0

[ pure-data-Bugs-3543466 ] debian: Cannot quit Pd if jackd was autostarted
by SourceForge.net 13 Jul '12

13 Jul '12

Bugs item #3543466, was opened at 2012-07-13 02:15 Message generated for change (Tracker Item Submitted) made by lorenzosu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3543466&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lorenzo (lorenzosu) Assigned to: Hans-Christoph Steiner (eighthave) Summary: debian: Cannot quit Pd if jackd was autostarted Initial Comment: On debian testing: - start Pd with no jackd running - jackd will be started by Pd - Quit Pd (with ctrl-q, from menu, by closing window) - Pd hangs with "watchdog: signaling pd..." If you do a: killall -9 jackd that also kills Pd This does not happen if jackd was previously started and Pd connects to it. jackd is version 1.9.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3543466&group_…

1 0

[ pure-data-Bugs-3541610 ] moonlib/image helpfile no image found
by SourceForge.net 09 Jul '12

09 Jul '12

Bugs item #3541610, was opened at 2012-07-09 07:39 Message generated for change (Tracker Item Submitted) made by ailo-at You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3541610&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: v0.43 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ailo (ailo-at) Assigned to: Nobody/Anonymous (nobody) Summary: moonlib/image helpfile no image found Initial Comment: This external has worked for me in the past, but on another OS (Ubuntu Oneiric). This OS is Debian Wheezy AMD64 Used latest pd-exteneded auto-build, and also built one version from source (rsync -av --delete rsync://128.238.56.50/distros/pd-extended/) This is the error message in the pd console: (Tcl) UNHANDLED ERROR: image "examples/play.gif" doesn't exist while executing ".x19ab680.c itemconfigure 190d0e0S -image examples/play.gif" ("uplevel" body line 22) invoked from within "uplevel #0 $cmds_from_pd" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3541610&group_…

1 0

[ pure-data-Bugs-3541431 ] iemnet/tcpclient
by SourceForge.net 08 Jul '12

08 Jul '12

Bugs item #3541431, was opened at 2012-07-08 12:52 Message generated for change (Tracker Item Submitted) made by maxn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3541431&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: max (maxn) Assigned to: Nobody/Anonymous (nobody) Summary: iemnet/tcpclient Initial Comment: Hi again I was able to create a patch, that does not make Pd crash reliably, but far more often. On my box it crashes roughly every second time I run the patch. This is how I run it: $ gdb -ex run --args pd-extended -noprefs -nrt -noaudio -stderr -open crashertest.pd When the [bng] is hit, every 10ms an OSC message is sent over TCP. After a while (on my box usually only a few seconds), no more messages are received, though they are still sent. If [iemnet/tcpclient] is disconnected at this point, Pd often crashes with the following backtrace: --- Program received signal SIGSEGV, Segmentation fault. 0x08086e42 in clock_unset (x=0x817f5b8) at m_sched.c:70 70 m_sched.c: No such file or directory. in m_sched.c (gdb) backtrace #0 0x08086e42 in clock_unset (x=0x817f5b8) at m_sched.c:70 #1 0x08086fb2 in clock_free (x=0x817f5b8) at m_sched.c:131 #2 0x00707ce0 in iemnet__receiver_destroy (rec=0x817f4c8) at iemnet_receiver.c:303 #3 0x007022e0 in tcpclient_disconnect (x=0x81042b8) at tcpclient.c:188 #4 0x0807f3f2 in pd_typedmess (x=0x81042b8, s=0x80f11e8, argc=<value optimized out>, argv=0xbffff1fc) at m_class.c:791 #5 0x080807fa in outlet_anything (x=0x8113e70, s=0x80f11e8, argc=0, argv=0xbffff1fc) at m_obj.c:470 #6 0x0807efe6 in pd_typedmess (x=0x8113e5c, s=0x80f11e8, argc=0, argv=0xbffff1fc) at m_class.c:812 #7 0x08085782 in binbuf_eval (x=0x8113e88, target=0x8113e5c, argc=0, argv=0x0) at m_binbuf.c:767 #8 0x0805fe2b in message_bang (x=0x8113e40) at g_text.c:351 #9 0x080804d3 in outlet_bang (x=0x8115bb0) at m_obj.c:399 #10 0x007137eb in delay_tick (x=0x8115b68) at delay.c:43 #11 0x08087414 in sched_tick (next_sys_time=49233920) at m_sched.c:372 #12 0x0808780b in m_pollingscheduler () at m_sched.c:485 #13 m_mainloop () at m_sched.c:571 #14 0x0808f14b in main (argc=7, argv=0xbffff3d4) at s_entry.c:32 --- This is with Pd-0.43.1-extended-20120307 With Pd-vanilla and the necessary externals, I get the same kind of crash, but a different (corrupt) backtrace: --- Program received signal SIGSEGV, Segmentation fault. 0x080a1fe5 in clock_unset (x=0x8140768) at m_sched.c:70 70 while (x2->c_next != x) x2 = x2->c_next; (gdb) backtrace #0 0x080a1fe5 in clock_unset (x=0x8140768) at m_sched.c:70 #1 0x080a217c in clock_free (x=0x8140768) at m_sched.c:131 #2 0x00501b79 in iemnet__receiver_destroy () from /usr/local/lib/pd/extra/iemnet/libiemnet.so #3 0x08140768 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) --- The fact, that [iemnet/tcpclient] suddenly stops transmitting data, indicates that there is some problem there, whether the crash is caused by it or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3541431&group_…

1 0

Compilation failure on Lucid 64
by András Murányi 05 Jul '12

05 Jul '12

Dear List, i've just noticed that the pd-extended build has been failing here on Ubuntu Lucid 64-bit for more than a month. This is the last part of the log (I've cut off the part where the script is trying to rsync the non-existent build...): gcc -DPACKAGE_NAME=\"pd\" -DPACKAGE_TARNAME=\"pd\" -DPACKAGE_VERSION=\"0.43.1\" -DPACKAGE_STRING=\"pd\ 0.43.1\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"pd\" -DVERSION=\"0.43.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBDL=1 -DSTDC_HEADERS=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SYS_SOUNDCARD_H=1 -DHAVE_UNISTD_H=1 -I. -DPD -DINSTALL_PREFIX=\"/usr\" -DUSEAPI_ALSA -DUSEAPI_JACK -DJACK_XRUN -DUSEAPI_OSS -DUSEAPI_PORTAUDIO -I../portaudio/include -O2 -g -MT pd-s_audio_oss.o -MD -MP -MF .deps/pd-s_audio_oss.Tpo -c -o pd-s_audio_oss.o `test -f 's_audio_oss.c' || echo './'`s_audio_oss.c s_audio_oss.c: In function ‘oss_configure’: s_audio_oss.c:205: error: ‘SOUND_PCM_GETOSPACE_is_obsolete_use_SNDCTL_DSP_GETOSPACE_instead’ undeclared (first use in this function) s_audio_oss.c:205: error: (Each undeclared identifier is reported only once s_audio_oss.c:205: error: for each function it appears in.) s_audio_oss.c: In function ‘oss_open_audio’: s_audio_oss.c:465: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result s_audio_oss.c:478: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result s_audio_oss.c: In function ‘oss_calcspace’: s_audio_oss.c:517: error: ‘SOUND_PCM_GETOSPACE_is_obsolete_use_SNDCTL_DSP_GETOSPACE_instead’ undeclared (first use in this function) s_audio_oss.c:524: error: ‘SOUND_PCM_GETISPACE_is_obsolete_use_SNDCTL_DSP_GETISPACE_instead’ undeclared (first use in this function) s_audio_oss.c: In function ‘oss_doresync’: s_audio_oss.c:572: error: ‘SOUND_PCM_GETISPACE_is_obsolete_use_SNDCTL_DSP_GETISPACE_instead’ undeclared (first use in this function) s_audio_oss.c:601: error: ‘SOUND_PCM_GETOSPACE_is_obsolete_use_SNDCTL_DSP_GETOSPACE_instead’ undeclared (first use in this function) make[5]: *** [pd-s_audio_oss.o] Error 1 make[5]: Leaving directory `/home/pd/auto-build/pd-extended/pd/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/pd/auto-build/pd-extended/pd/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/pd/auto-build/pd-extended/pd' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/pd/auto-build/pd-extended/pd' make[1]: *** [pd] Error 2 make[1]: Leaving directory `/home/pd/auto-build/pd-extended/packages' make: *** [install] Error 2 András

1 0

open_via_path / close file - WIndows CRT problems
by Thomas Grill 04 Jul '12

04 Jul '12

Hi all, when trying to trace a bug in one of my externals i came across what could be an issue in the PD API. The header m_pd.h exposes the function open_via_path which can be used in externals to search file in the PD search path. On success it opens the file and returns a file handle, which can in turn be used by the external code. This doesn't seem to be a problem on Unix-based systems. On Windows, under certain circumstances [1], PD and the external use separate copies of the CRT, meaning that passing the file handle and using POSIX-style file functions between dynamically linked binaries is not really possible. The file handle would not be valid in the external. This happens when at least one party is linked with the threaded static CRT, which is the default with PD and most externals. Now, i'm wondering how this problem can have been hidden for so long. Are there no externals using open_via_path and running under Windows? This must be a problem for all script loader externals relying on the PD path, like my py/pyext external. Am i doing something wrong, or is there a known solution/workaround etc.? Thanks and all the best, Thomas [1] http://msdn.microsoft.com/en-us/library/ms235460(v=vs.80).aspx -- Thomas Grill http://grrrr.org

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev July 2012