Patches item #3528891, was opened at 2012-05-22 10:42
Message generated for change (Settings changed) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3528891&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: puredata
Group: bugfix
>Status: Pending
>Resolution: Accepted
Priority: 3
Private: No
Submitted By: Glen F (totalgee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fixing a few compiler warnings on OS X (LLVM)
Initial Comment:
A few very minor changes.
A couple of these fix pointer dereferencing which was subsequently not used (has no effect other than causing a warning with the LLVM compiler on OS X). The only important part is the advancing (++) of the pointers, which remains as it was. In the other case, an error() function with variable arguments was being printed using an uncontrolled format string (http://en.wikipedia.org/wiki/Uncontrolled_format_string). In the context of the actual code, I don't think it actually is a safety issue -- but it does get rid of another compiler warning/error with the latest LLVM compiler.
This is my first (admittedly very minor) patch submission, I hope it's okay. I had submitted a pull request on the libpd GitHub project, but they informed me it was better to apply it to the original Pd "vanilla" source, which they just bring over verbatim from time to time.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3528891&group_…
Patches item #3528911, was opened at 2012-05-22 12:26
Message generated for change (Settings changed) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3528911&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: puredata
Group: feature
>Status: Pending
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Jan Berkel (jberkel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better support for loading externals on Android
Initial Comment:
Native libs on Android have a few restrictions - they need to start with "lib", end in ".so" and may not contain tilde ('~'). At the moment apps using pd on Android work around this problem by renaming files, putting them into a zip archive and unzipping this archive when the app starts.
It would be nice to be able to load them directly from the app's lib directory. The attached patch changes the loader so that when resolving "z~" it will also look for "libz_tilde.so" in the current search path.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3528911&group_…
Patches item #3539048, was opened at 2012-06-29 13:17
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3539048&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: feature
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: eriacta reviews
Initial Comment:
eriacta reviews
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3539048&group_…
Bugs item #3537988, was opened at 2012-06-25 18:46
Message generated for change (Tracker Item Submitted) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3537988&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: Dan WIlcox ()
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: enter key in GOP edit closes dialog
Initial Comment:
On Mac OSX 10.7.4 with pd-extended 0.43.1 20120612
Normally, I change the GOP sizes bit by bit until things match by adjusting the number in the GOP edit dialog, hitting enter to see changes, and finally closing the dialog when I'm satisfied. This is much more tedious in the beta pd-ext as hitting enter always closes the dialog. So now I have to reopen the dialog each time I want to tweak the number .... very inconvenient.
I did;t check but I imagine this may be similar in other dialogs ...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3537988&group_…
Bugs item #3537542, was opened at 2012-06-24 07:36
Message generated for change (Tracker Item Submitted) made by nusmuk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3537542&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: pd~ halt pd using stdout with -noutsig 0
Initial Comment:
When using pd~ with argument -noutsig 0 , using the stdout object from the pd~ patch can halt both pd.
This can be reproduced using pd~ help file, modifying pd~ argument to [pd~ -ninsig 2 -noutsig 0 -fifo 20]
start pd~
click on the message [a b c> from the pd~-subprocess patch.
both pd halt.
using pd 0.43.3test1 / linux
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3537542&group_…
Patches item #3505262, was opened at 2012-03-15 07:33
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3505262&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: puredata
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: slightly increase buffers when dealing with UTF8
Initial Comment:
running Pd through valgrind [1] gives a number of "Invalid read" errors, as soon as you create an object and type a single letter (e.g. "f").
creating the object (by licking besides it), gives another number of "Invalid read" errors.
those errors suggest that memory outside the allocated buffer is accessed. it seems that all these errors are related to the UTF-8 code (since with utf-8 we might have to check multiple bytes).
the attached fix simply increases the allocated buffer slightly (more than what happens already), so the read can take place on safe grounds.
[1] like with $ valgrind --tool=memcheck --leak-check=full ./src/pd -noprefs -nrt -noaudio -stderr
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-06-22 15:19
Message:
applied to 0.43-3 test
----------------------------------------------------------------------
Comment By: Marvin Humphrey (creamygoodness)
Date: 2012-03-15 08:22
Message:
The existing UTF-8 processing code assumes that strings are NUL-terminated
and feels free to access that NUL byte beyond the buffer. However, the
strings PD uses are always paired with a length, so it is possible to
perform UTF-8 processing without going past the end of the buffer. That
other patch gets rid of the overruns, and applying it should indeed clear
the Valgrind errors that inspired both patches.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-03-15 07:47
Message:
seems like it is duplicate patches day for me:
https://sourceforge.net/tracker/?func=detail&aid=3420484&group_id=55736&ati…
i haven't really checked the other patch, but it seems like it addresses
the same issues while curing the cause rather than the symptoms.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3505262&group_…
Patches item #3534907, was opened at 2012-06-13 08:22
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3534907&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: puredata
Group: None
>Status: Pending
Resolution: None
Priority: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: Pd crashes when deleting (used) array via GUI
Initial Comment:
via the properties of an array you can delete the given array (this is useful if you have multiple arrays in one graph and want to get rid of one)
unfortunately doing so can lead to a crash, if the thus-deleted array is used in a DSP-object.
the reason for this is that dsp-arrays will usually only check for the existence of a table when the dsp-graph is compiled (dsp-method), but the GUI-deletion does not trigger a re-compilation of the dsp-graph.
attached is a small example patch to trigger the problem
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-06-22 15:18
Message:
applied to 0.43-3 test
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-06-13 08:34
Message:
attached is a git-patch against current head (0.43-2) that calls
canvas_update_dsp() if the deleted array is flagged as being used in dsp
calculations.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3534907&group_…
Patches item #3536805, was opened at 2012-06-21 00:10
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3536805&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: puredata
Group: None
>Status: Pending
Resolution: Fixed
Priority: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: [tabread4~] crashes with illegal tablesizes
Initial Comment:
as reported for the debian-package of Pd [1], pd can crash when using [tabread4~] and loading an invalid (raw) file into the table using [soundfiler].
"invalid" file means, that a (raw) file is read with a "headersize" (to skip) that is actually larger than the entire file.
[soundfiler] will attempt to resize the table to something negative (since filelength-headersize<0) which will fail safely, and leave the table at a size=1.
however, a [tabread4~] that accesses this table might segfault, since it needs more than 1 sample to interpolate.
for a patch that triggers the problem, see [1].
it seems that the problem only appears on x86_64, and not on i386.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678306
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2012-06-22 15:18
Message:
applied to 0.43-3test
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-06-21 00:22
Message:
attached is a patch that fixes the problem.
the patch does:
- make [soundfiler] fail if lseek(CUR)>lseek(EOF) (which is the case if the
specified header is larger than the soundfile); this is not strictly
necessary, since the array-resize will not resize to negative lengths.
- make [tabread4~] fallback to zeroes, if the table is smaller than 4
samples.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3536805&group_…
Patches item #3536805, was opened at 2012-06-21 00:10
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3536805&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: puredata
Group: None
Status: Open
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
>Assigned to: Miller Puckette (millerpuckette)
Summary: [tabread4~] crashes with illegal tablesizes
Initial Comment:
as reported for the debian-package of Pd [1], pd can crash when using [tabread4~] and loading an invalid (raw) file into the table using [soundfiler].
"invalid" file means, that a (raw) file is read with a "headersize" (to skip) that is actually larger than the entire file.
[soundfiler] will attempt to resize the table to something negative (since filelength-headersize<0) which will fail safely, and leave the table at a size=1.
however, a [tabread4~] that accesses this table might segfault, since it needs more than 1 sample to interpolate.
for a patch that triggers the problem, see [1].
it seems that the problem only appears on x86_64, and not on i386.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678306
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2012-06-21 00:22
Message:
attached is a patch that fixes the problem.
the patch does:
- make [soundfiler] fail if lseek(CUR)>lseek(EOF) (which is the case if the
specified header is larger than the soundfile); this is not strictly
necessary, since the array-resize will not resize to negative lengths.
- make [tabread4~] fallback to zeroes, if the table is smaller than 4
samples.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3536805&group_…
Bugs item #3536805, was opened at 2012-06-21 00:10
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3536805&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Nobody/Anonymous (nobody)
Summary: [tabread4~] crashes with illegal tablesizes
Initial Comment:
as reported for the debian-package of Pd [1], pd can crash when using [tabread4~] and loading an invalid (raw) file into the table using [soundfiler].
"invalid" file means, that a (raw) file is read with a "headersize" (to skip) that is actually larger than the entire file.
[soundfiler] will attempt to resize the table to something negative (since filelength-headersize<0) which will fail safely, and leave the table at a size=1.
however, a [tabread4~] that accesses this table might segfault, since it needs more than 1 sample to interpolate.
for a patch that triggers the problem, see [1].
it seems that the problem only appears on x86_64, and not on i386.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678306
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3536805&group_…