My friend Dichotomie ( Binary search algorithm ) has helped me out to find out the problem with this patch.
just replace "print NO_match" by "print Nomatch"
it's seems there's a problem with stdout or something like this I'll try to pay attention to warnings during next compile unless someone finds out that micromagic...
Patrice Colet - 06 32 66 03 57
----- "patko" colet.patrice@free.fr a écrit :
The problem is one light year beyond what I've suggested first, sorry, it comes from the help patch.
It's very hard to figure out what's going on, and watching what's happening by modifying things by hand with a text editor might help to find out the kinky lines, good luck!
Why not trying out select-help.pd from vanilla or older one in svn?
Patrice Colet - 06 32 66 03 57
----- "rene beekman" r@raakvlak.net a écrit :
tested this tonight on one machine running win7. replacing the pd.dll in the pd/bin folder made pd unable to
start....
On May 08, 2010, at 16:38, patko wrote:
I've recently compiled a version of pd-extended just replacing pd.dll fixes it, it's attached
----- "rene beekman" r@raakvlak.net a écrit :
i reported this problem several months ago. the suggestion back then was to test nightly builds, which did
not
work at the time. more recent nightly builds did not solve this problem either.
it appears on some laptops running vista or windows7, but not
all.
i have so far not been able to recreate this problem on a
machine
that
did not have the problem.
has anyone else seen this problem? been able to solve it?
i have several pd courses coming up for which i'm expecting the majority of participants to be running windoze - they will be
brining
in their own machines. problem is, once into the courses i will not have the time to troubleshoot this kind of problem and i dread going into this
knowing
that any machine running vista or windows7 is potentially
unstable...
would greatly appreciate help in figuring this out
rene
On Feb 14, 2010, at 19:23, Hans-Christoph Steiner wrote:
try a Pd-extended 0.42.5 nightly build
try this version with the [multiselect] object removed from
the
"related objects" subpatch
<select-help.pd>
.hc
On Feb 14, 2010, at 7:59 AM, rene beekman wrote:
we're having problems running pd-extended 0.41.4 on vista &
windows7
problems seem to be related to several particular objects or
patches
one example is the select-help patch. opening the help patch
either
via the desktop, or from within pd via the browser or via the
context
menu's 'help' option results in windows closing pd
the application error log on one particular machine shows
this:
Faulting application pd.exe, version 0.0.0.0, time stamp
0x4a277929, faulting module ntdll.dll, version 6.0.6002.18005,
time
stamp 0x49e03821, exception code 0xc0000005, fault offset
0x00041f3c,
process id 0x1534, application start time 0x01caad6a4a506d60.
on the windows7 machine, it is the same library that is marked
as
"faulting module", only it's a 6.1 version
is this a known bug? any workarounds?
thanks in advance
rene
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
"We have nothing to fear from love and commitment." - New York
Senator Diane Savino, trying to convince the NY Senate to pass a
gay
marriage bill
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
<pd.dll-win32-6.0.zip>
just replace "print NO_match" by "print Nomatch"
in fact print doesn't support more than seven characters is argument symbol
the bug is easy to reproduce: in a new patch create a [print aaaaaaaa] object and close, it will crash, but under certain conditions, it doesn't crash with the version I often use, and I've no clue why, this bug is so tricky, it looks like a windows memory restriction nightmare.
I'm certain the bug come from those lines from x_interface.c:
if (argc)
{
t_binbuf *bb = binbuf_new();
binbuf_add(bb, argc, argv);
binbuf_gettext(bb, &buf, &bufsize);
buf[bufsize] = 0;
x->x_sym = gensym(buf);
binbuf_free(bb);
}
if you remove this the arg symbol won't crash pd.
it's just weird.
many thanks, i made the necessary changes to the select help patch and will be trying this modified patch in the coming days on several machines. will post updates when i have more.
thanks again.
rene
On May 10, 2010, at 18:28, patko wrote:
just replace "print NO_match" by "print Nomatch"
in fact print doesn't support more than seven characters is argument symbol
the bug is easy to reproduce: in a new patch create a [print aaaaaaaa] object and close, it will crash, but under certain conditions, it doesn't crash with the version I often use, and I've no clue why, this bug is so tricky, it looks like a windows memory restriction nightmare.
I'm certain the bug come from those lines from x_interface.c:
if (argc) { t_binbuf *bb = binbuf_new(); binbuf_add(bb, argc, argv); binbuf_gettext(bb, &buf, &bufsize); buf[bufsize] = 0; x->x_sym = gensym(buf); binbuf_free(bb); }
if you remove this the arg symbol won't crash pd.
it's just weird.
i made the suggested change to the [sel] help patch and now have confirmation on 2 out of 3 i've seen machines with these problems, that the modified patch no longer crashes pd.
this is a weeeeiiiiird problem that would have been extremely hard to find without your help. thanks!
looking forward to any solution to this making it into the nightly builds :)
rene
On May 10, 2010, at 11:27, patko wrote:
My friend Dichotomie ( Binary search algorithm ) has helped me out to find out the problem with this patch.
just replace "print NO_match" by "print Nomatch"
it's seems there's a problem with stdout or something like this I'll try to pay attention to warnings during next compile unless someone finds out that micromagic...
Patrice Colet - 06 32 66 03 57
----- "patko" colet.patrice@free.fr a écrit :
The problem is one light year beyond what I've suggested first, sorry, it comes from the help patch.
It's very hard to figure out what's going on, and watching what's happening by modifying things by hand with a text editor might help to find out the kinky lines, good luck!
Why not trying out select-help.pd from vanilla or older one in svn?
Patrice Colet - 06 32 66 03 57
----- "rene beekman" r@raakvlak.net a écrit :
tested this tonight on one machine running win7. replacing the pd.dll in the pd/bin folder made pd unable to
start....
On May 08, 2010, at 16:38, patko wrote:
I've recently compiled a version of pd-extended just replacing pd.dll fixes it, it's attached
----- "rene beekman" r@raakvlak.net a écrit :
i reported this problem several months ago. the suggestion back then was to test nightly builds, which did
not
work at the time. more recent nightly builds did not solve this problem either.
it appears on some laptops running vista or windows7, but not
all.
i have so far not been able to recreate this problem on a
machine
that
did not have the problem.
has anyone else seen this problem? been able to solve it?
i have several pd courses coming up for which i'm expecting the majority of participants to be running windoze - they will be
brining
in their own machines. problem is, once into the courses i will not have the time to troubleshoot this kind of problem and i dread going into this
knowing
that any machine running vista or windows7 is potentially
unstable...
would greatly appreciate help in figuring this out
rene
On Feb 14, 2010, at 19:23, Hans-Christoph Steiner wrote:
try a Pd-extended 0.42.5 nightly build
try this version with the [multiselect] object removed from
the
"related objects" subpatch
<select-help.pd>
.hc
On Feb 14, 2010, at 7:59 AM, rene beekman wrote:
> we're having problems running pd-extended 0.41.4 on vista &
windows7
> problems seem to be related to several particular objects or
patches
> one example is the select-help patch. opening the help patch
either
via the desktop, or from within pd via the browser or via the
context
menu's 'help' option results in windows closing pd
> > the application error log on one particular machine shows
this:
> > Faulting application pd.exe, version 0.0.0.0, time stamp
0x4a277929, faulting module ntdll.dll, version 6.0.6002.18005,
time
stamp 0x49e03821, exception code 0xc0000005, fault offset
0x00041f3c,
process id 0x1534, application start time 0x01caad6a4a506d60.
> > on the windows7 machine, it is the same library that is marked
as
"faulting module", only it's a 6.1 version
> > is this a known bug? > any workarounds? > > thanks in advance > > rene > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management ->
"We have nothing to fear from love and commitment." - New York
Senator Diane Savino, trying to convince the NY Senate to pass a
gay
marriage bill
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
<pd.dll-win32-6.0.zip>
I'm afraid the print source will stay like this unless someone that knows very well c code explain what's happening, I gave all the keys but without a dev to end the work, there is nothing else to do.
And I think this is stupid to just 'avoid' to put more than seven characters in print argument, also it doesn't always crash, so if the dev that has a windows >= 6.0 don't see the problem, like on my machine the first time, he won't correct the problem.
Maybe opening a new topic with "[print] crashes pd" would make it.
the problem is exactly there:
x_interface.c:28 buf[bufsize] = 0;
remove or comment this line, then it won't crash anymore.
I've no clue what this line stand for.
On Wed, 12 May 2010, patko wrote:
Maybe opening a new topic with "[print] crashes pd" would make it. the problem is exactly there: x_interface.c:28 buf[bufsize] = 0; remove or comment this line, then it won't crash anymore. I've no clue what this line stand for.
If you have no clue, then perhaps you are replacing a bug by another bug. This looks like it's a bug regardless of the OS, although it currently only shows up on some versions of Windows. What you suggest seems to be a bug on any OS as well. Instead of removing the line, try prepending it with :
buf = resizebytes(buf, bufsize+1, bufsize);
(I hope I didn't make any mistake there... but looks ok to me now).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
----- "Mathieu Bouchard" matju@artengine.ca a écrit :
On Wed, 12 May 2010, patko wrote:
the problem is exactly there: x_interface.c:28 buf[bufsize] = 0;
This looks like it's a bug regardless of the OS, although it currently
only shows up on some versions of Windows. What you suggest seems to be a bug on any OS as well. Instead of removing the line, try prepending it
with :
buf = resizebytes(buf, bufsize+1, bufsize);
(I hope I didn't make any mistake there... but looks ok to me now).
No mistakes, that's alright with my OS.
----- "patko" colet.patrice@free.fr a écrit :
----- "Mathieu Bouchard" matju@artengine.ca a écrit :
buf = resizebytes(buf, bufsize+1, bufsize);
(I hope I didn't make any mistake there... but looks ok to me now).
No mistakes, that's alright with my OS.
oupse, I didn't pay attention but it also add extra characters to [print argument]
match : bang NO_matchû@ﾳ.: 234
they are not just the same char than with HC's solution, but in both cases it doesn't crash anymore.
On Fri, 14 May 2010, patko wrote:
but in both cases it doesn't crash anymore.
AND i wanted to say that it's also "luck" that it doesn't crash anymore.
It would be more instructive and helpful if a programme would crash every time that the code does something wrong, but alas, this is not the case.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On May 14, 2010, at 10:08 AM, Mathieu Bouchard wrote:
On Fri, 14 May 2010, patko wrote:
but in both cases it doesn't crash anymore.
AND i wanted to say that it's also "luck" that it doesn't crash
anymore.It would be more instructive and helpful if a programme would crash
every time that the code does something wrong, but alas, this is not
the case.
Arg, this stuff is maddening. If you look at scalar_properties() in
g_scalar.c, you'll see Miller does the opposite with that resize, the
+1 is in the new size, not the old. I think I'll try it like that.
binbuf_add(bb, argc, argv);
binbuf_gettext(bb, &buf, &bufsize);
buf = t_resizebytes(buf, bufsize, bufsize+1);
buf[bufsize] = 0;
x->x_sym = gensym(buf);
binbuf_free(bb);
.hc
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
On May 12, 2010, at 1:43 PM, Mathieu Bouchard wrote:
On Wed, 12 May 2010, patko wrote:
Maybe opening a new topic with "[print] crashes pd" would make it. the problem is exactly there: x_interface.c:28 buf[bufsize] = 0; remove or comment this line, then it won't crash anymore. I've no clue what this line stand for.
If you have no clue, then perhaps you are replacing a bug by another
bug. This looks like it's a bug regardless of the OS, although it
currently only shows up on some versions of Windows. What you
suggest seems to be a bug on any OS as well. Instead of removing the
line, try prepending it with :buf = resizebytes(buf, bufsize+1, bufsize);
(I hope I didn't make any mistake there... but looks ok to me now).
Shouldn't this work instead:
buf[bufsize-1] = 0;
.hc
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Thu, 13 May 2010, Hans-Christoph Steiner wrote:
On May 12, 2010, at 1:43 PM, Mathieu Bouchard wrote:
Instead of removing the line, try prepending it with : buf = resizebytes(buf, bufsize+1, bufsize); (I hope I didn't make any mistake there... but looks ok to me now).
Shouldn't this work instead: buf[bufsize-1] = 0;
it doesn't crash, but it removes the last character from the string, so, it doesn't work.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On May 12, 2010, at 1:43 PM, Mathieu Bouchard wrote:
On Wed, 12 May 2010, patko wrote:
Maybe opening a new topic with "[print] crashes pd" would make it. the problem is exactly there: x_interface.c:28 buf[bufsize] = 0; remove or comment this line, then it won't crash anymore. I've no clue what this line stand for.
If you have no clue, then perhaps you are replacing a bug by another
bug. This looks like it's a bug regardless of the OS, although it
currently only shows up on some versions of Windows. What you
suggest seems to be a bug on any OS as well. Instead of removing the
line, try prepending it with :buf = resizebytes(buf, bufsize+1, bufsize);
(I hope I didn't make any mistake there... but looks ok to me now).
Or maybe:
binbuf_gettext(bb, &buf, &bufsize);
strncat(buf, "\0", strlen(buf)-bufsize);
x->x_sym = gensym(buf);
http://at.or.at/hans/
On Thu, 13 May 2010, Hans-Christoph Steiner wrote:
Or maybe: binbuf_gettext(bb, &buf, &bufsize); strncat(buf, "\0", strlen(buf)-bufsize);
strncat will copy at most strlen(buf)-bufsize, but it will also copy at most strlen("\0") bytes, and strlen("\0") is zero, because strlen actually is just
long strlen (const char *start) { const char *end = start; while (*end) end++; return end-start; }
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Thu, 13 May 2010, Mathieu Bouchard wrote:
On Thu, 13 May 2010, Hans-Christoph Steiner wrote:
Or maybe: binbuf_gettext(bb, &buf, &bufsize); strncat(buf, "\0", strlen(buf)-bufsize);
strncat will copy at most strlen(buf)-bufsize, but it will also copy at most strlen("\0") bytes, and strlen("\0") is zero, because strlen actually is just long strlen (const char *start) { const char *end = start; while (*end) end++; return end-start; }
... but also, strncat(buf,...) needs a well-defined strlen(buf) in the first place, which only exists if buf has a null terminator before you start. only in this case, strncat will be guaranteed to have the correct behaviour, which is to have no effect at all in this case.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Wed, 12 May 2010, Mathieu Bouchard wrote:
buf = resizebytes(buf, bufsize+1, bufsize);
indeed, oldsize comes before, not after, so,
buf = resizebytes(buf, bufsize, bufsize+1);
as Hans said.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Hans-Christoph Steiner -
Mathieu Bouchard -
patko -
rene beekman