Patches item #1930733, was opened at 2008-03-31 18:02
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Miller Puckette (millerpuckette)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2008-05-26 09:46
Message:
Logged In: YES
user_id=313747
Originator: NO
It will work fine to allow MAXARG+1 arguments (6) to vmess; the
MAXARGS restriction in typedmess() is unrelated. I think that's
the best way since apparently some code exists that depends on
MAXARG+1. It's not clear what the maximum should really be; since
this is a convenience routine anyway, I'm thinking it should be
expanded, say to 10 or so.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-26 08:57
Message:
Logged In: YES
user_id=27104
Originator: NO
It seems to me that the logic of the function needs to change, but adding
+1 to the array will prevent the overflow, though it's not a very clean way
to do it.
Works for now, I suppose.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-05-26 00:32
Message:
Logged In: YES
user_id=564396
Originator: NO
as thomas has pointed out, there _is_ a buffer overrun which should be
fixed rather than merely unapplying the patch because it gives weird error
messages.
so for the ease of applying it, here is the patch that fixes the leak by
adding an additional element to the array (i'll apply it to pd-ext 0.40)
Index: m_class.c
===================================================================
--- m_class.c (Revision 9919)
+++ m_class.c (Arbeitskopie)
@@ -772,7 +772,7 @@
void pd_vmess(t_pd *x, t_symbol *sel, char *fmt, ...)
{
va_list ap;
- t_atom arg[MAXPDARG], *at =arg;
+ t_atom arg[MAXPDARG+1], *at =arg;
int nargs = 0;
char *fp = fmt;
----------------------------------------------------------------------
Comment By: Thomas Grill (xovo)
Date: 2008-05-26 00:17
Message:
Logged In: YES
user_id=350252
Originator: YES
Is the arg array too small then and must have MAXPDARGS+1 elements
instead?
In the loop, the "at" pointer subsequently points to the elements of
"arg". If the switch statement is reached with a value of "nargs ==
MAXPDARG", then "arg" points to a position outside the array.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 14:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 16:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…
Patches item #1930733, was opened at 2008-03-31 21:02
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Miller Puckette (millerpuckette)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-26 11:57
Message:
Logged In: YES
user_id=27104
Originator: NO
It seems to me that the logic of the function needs to change, but adding
+1 to the array will prevent the overflow, though it's not a very clean way
to do it.
Works for now, I suppose.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-05-26 03:32
Message:
Logged In: YES
user_id=564396
Originator: NO
as thomas has pointed out, there _is_ a buffer overrun which should be
fixed rather than merely unapplying the patch because it gives weird error
messages.
so for the ease of applying it, here is the patch that fixes the leak by
adding an additional element to the array (i'll apply it to pd-ext 0.40)
Index: m_class.c
===================================================================
--- m_class.c (Revision 9919)
+++ m_class.c (Arbeitskopie)
@@ -772,7 +772,7 @@
void pd_vmess(t_pd *x, t_symbol *sel, char *fmt, ...)
{
va_list ap;
- t_atom arg[MAXPDARG], *at =arg;
+ t_atom arg[MAXPDARG+1], *at =arg;
int nargs = 0;
char *fp = fmt;
----------------------------------------------------------------------
Comment By: Thomas Grill (xovo)
Date: 2008-05-26 03:17
Message:
Logged In: YES
user_id=350252
Originator: YES
Is the arg array too small then and must have MAXPDARGS+1 elements
instead?
In the loop, the "at" pointer subsequently points to the elements of
"arg". If the switch statement is reached with a value of "nargs ==
MAXPDARG", then "arg" points to a position outside the array.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 17:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 19:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…
Patches item #1930733, was opened at 2008-04-01 03:02
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Miller Puckette (millerpuckette)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-05-26 09:32
Message:
Logged In: YES
user_id=564396
Originator: NO
as thomas has pointed out, there _is_ a buffer overrun which should be
fixed rather than merely unapplying the patch because it gives weird error
messages.
so for the ease of applying it, here is the patch that fixes the leak by
adding an additional element to the array (i'll apply it to pd-ext 0.40)
Index: m_class.c
===================================================================
--- m_class.c (Revision 9919)
+++ m_class.c (Arbeitskopie)
@@ -772,7 +772,7 @@
void pd_vmess(t_pd *x, t_symbol *sel, char *fmt, ...)
{
va_list ap;
- t_atom arg[MAXPDARG], *at =arg;
+ t_atom arg[MAXPDARG+1], *at =arg;
int nargs = 0;
char *fp = fmt;
----------------------------------------------------------------------
Comment By: Thomas Grill (xovo)
Date: 2008-05-26 09:17
Message:
Logged In: YES
user_id=350252
Originator: YES
Is the arg array too small then and must have MAXPDARGS+1 elements
instead?
In the loop, the "at" pointer subsequently points to the elements of
"arg". If the switch statement is reached with a value of "nargs ==
MAXPDARG", then "arg" points to a position outside the array.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 23:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-16 01:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…
Patches item #1930733, was opened at 2008-04-01 01:02
Message generated for change (Settings changed) made by xovo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Open
>Resolution: None
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
>Assigned to: Miller Puckette (millerpuckette)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
Comment By: Thomas Grill (xovo)
Date: 2008-05-26 07:17
Message:
Logged In: YES
user_id=350252
Originator: YES
Is the arg array too small then and must have MAXPDARGS+1 elements
instead?
In the loop, the "at" pointer subsequently points to the elements of
"arg". If the switch statement is reached with a value of "nargs ==
MAXPDARG", then "arg" points to a position outside the array.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 21:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 23:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…
Patches item #1930733, was opened at 2008-04-01 01:02
Message generated for change (Settings changed) made by xovo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Open
Resolution: Invalid
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Thomas Grill (xovo)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
>Comment By: Thomas Grill (xovo)
Date: 2008-05-26 07:17
Message:
Logged In: YES
user_id=350252
Originator: YES
Is the arg array too small then and must have MAXPDARGS+1 elements
instead?
In the loop, the "at" pointer subsequently points to the elements of
"arg". If the switch statement is reached with a value of "nargs ==
MAXPDARG", then "arg" points to a position outside the array.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 21:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 23:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…
Patches item #1959417, was opened at 2008-05-07 04:15
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1959417&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: bugfix
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Martin Peach (mrpeach)
Summary: [unpackOSC] should output a message rather than a list
Initial Comment:
the current implementation of [unpackOSC] outputs a list instead of a message.
e.g. the OSC-message "/bla 1 2 3" will be output as "list /bla 1 2 3"
if you want to use [route] to dispatch the message, you therefore have to [list trim] (or [route list]) the "list"-selector away.
([routeOSC] handles these lists quite well)
the attached patch will internally trim the selector away and thus [unpackOSC] will output
"/bla 1 2 3"
([routeOSC] handles these quite well as well)
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-05-25 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Martin Peach (mrpeach)
Date: 2008-05-11 11:27
Message:
Logged In: YES
user_id=919007
Originator: NO
Patch applied, now wait to see if it works...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1959417&group_…
Bugs item #1848150, was opened at 2007-12-10 12:34
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1848150&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: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: wonderingwout (wonderingwout)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: pdp_qt does not load any type of movie (pd 0.40.3-extended)
Initial Comment:
Hard- and software details:
- MacBook 1,83 2GB ram with MacOSX Leopard 10.5.1
- Pd-0.40.3-extended-20071207.app
Error message:
pdp_qt: opening /Users/wout/Documents/PureData/VJ-tool/files/disco1.mov
pdp_qt: video stream found (640x480 pixels, 15 fps, 20 frames, jpeg codec)
pdp_qt: WARNING: unsupported video codec
pdp_qt: ERROR: no usable video stream found.
I tried to load a movies with the following compression types:
- mpeg4
- jpeg
- sorensen video 3
- animation
- none
All with the same failure message.
The same patch with Pd version 0.39.3-extended-rc5 works.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-05-25 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-11 06:53
Message:
Logged In: YES
user_id=27104
Originator: NO
With Pd-extended 0.40.3-20080502 on Mac OS X 10.4.11/Intel I can play the
included anim-1.mov with no problems. Is this still a problem for you?
pdp_qt: opening
/Users/hans/code/pure-data/trunk/Gem/examples/data/anim-1.mov
pdp_qt: video stream found (256x256 pixels, 30 fps, 91 frames, jpeg
codec)
pdp_qt: using colormodel YUV420P
pdp_qt: /Users/hans/code/pure-data/trunk/Gem/examples/data/anim-1.mov
opened
I tried some other movies too, this one worked fine:
pdp_qt: opening /Users/hans/Movies/novnain.mov
pdp_qt: video stream found (320x240 pixels, 30 fps, 3084 frames, SVQ3
codec)
pdp_qt: audio stream found (1 channels, 32000 Hz, 3279744 samples,
chunksize 1067)
pdp_qt: using colormodel YUV420P
This one loaded and showed the first frame, then crashed:
pdp_qt: opening /Users/hans/Movies/explode.mov
pdp_qt: video stream found (320x240 pixels, 30 fps, 712 frames, SVQ1
codec)
pdp_qt: audio stream found (1 channels, 11025 Hz, 261600 samples,
chunksize 367)
pdp_qt: WARNING: unsupported audio codec
pdp_qt: using colormodel YUV420P
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1848150&group_…
Bugs item #1845770, was opened at 2007-12-06 12:15
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1845770&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: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: stereopticon (stereopticon)
Assigned to: Nobody/Anonymous (nobody)
Summary: PiDiP ascii renderer eats mac hard disks
Initial Comment:
...iknow, it sounds like a tabloid headline.
I'm running OSX 10.4.11 on a Macbook Pro 2.16 GHz Intel Core 2 Duo. I upgraded to pd 0.39.3-extended-rc5 recently and began messing around with the PiDiP ascii renderer. Early in a day of testing I loaded an 11-second, 640x480 quicktime clip compressed with the H.264 codec into pdp_ascii-help.pd and gotâŠnothing. The patch became completely unresponsive to mouse clicks and I ended up having to quit and relaunch pd and X11. I eventually discovered that pdp_ascii works with the Sorenson video 3 codec and spent a happy hour turning bits of things into ascii art.
Then I noticed something strange. The hard drive was nearly full. As I watched in shock, it filled up completely. A couple of minutes of searching found the culprit: my console log file for the session was 36 gigs. Turns out that all that space was taken up by a single message, âskipping corrupted frameâ, spit out over and over again at the ridiculous rate of 4 megs/sec. Trying to load the H.264 quicktime is what initiated the loop. Iâve been able to replicate it and came up with the following info: the bug runs independent of pd and X11, hogs 80% of the CPU, and since for some reason the process is tied to the OSX loginwindow process I was only able to kill it by logging out.
Cheers,
Michael
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-05-25 19:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-11 06:45
Message:
Logged In: YES
user_id=27104
Originator: NO
Is this still a problem on 0.40.3-extended test releases? It is
reproducable?
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-04-07 02:40
Message:
Logged In: YES
user_id=564396
Originator: NO
stupid me, but is the console log file part of os-x, pd-extended or did
you add it manually?
(imho, writing things (even if there are lots of things) to the console
does not really qualify as a bug)
furthermore, the log-message is likely not being emitted by pidip, but
rather by the underlying decoding library (libquicktime);
so the bug report should probably go there instead of here
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1845770&group_…
Patches item #1930733, was opened at 2008-03-31 21:02
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Invalid
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Thomas Grill (xovo)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 17:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 19:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…
Patches item #1930733, was opened at 2008-03-31 21:02
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&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: Open
>Resolution: Invalid
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
>Assigned to: Thomas Grill (xovo)
Summary: 0.41-4: prevent buffer overrun in m_class.c
Initial Comment:
the array only has MAXPDARG elements.......
--- m_class.ori.c 2008-04-01 03:00:09.000000000 +0200
+++ m_class.c 2008-04-01 03:00:12.000000000 +0200
@@ -763,7 +763,7 @@
va_start(ap, fmt);
while (1)
{
- if (nargs > MAXPDARG)
+ if (nargs >= MAXPDARG)
{
pd_error(x, "pd_vmess: only %d allowed", MAXPDARG);
break;
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-25 17:52
Message:
Logged In: YES
user_id=27104
Originator: NO
This patch causes this message when clicking on abstractions and
subpatches in run mode:
error: pd_vmess: only 5 allowed
... you might be able to track this down from the Find menu.
I think this patch might be invalid since nargs is only used to send to
typedmess() as argc, in which case 5 is the appropriate value.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-04-15 19:42
Message:
Logged In: YES
user_id=27104
Originator: NO
checked into branches/pd-extended/0.40
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1930733&group_…