Cool - pushed it to git repo.
thanks M
On Sun, Mar 06, 2016 at 08:52:59PM +0100, IOhannes m zmölnig wrote:
On 03/06/2016 08:21 PM, IOhannes m zmölnig wrote:
On 03/04/2016 11:22 AM, Christof Ressi wrote:
So you're probably right with your guess about memory corruption
actually, valgrind already proved that this was not a guess.
and with the help of valgrind it was also very easy to spot the actual problem: a pointer was not updated after calling binbuf_resize().
attached is a one-liner fix for the problem.
gfmards IOhannes
From ff63300dc38fb5d659c4bf9831ea5ddd05680a2c Mon Sep 17 00:00:00 2001 From: IOhannes m zmoelnig zmoelnig@umlautQ.umlaeute.mur.at Date: Sun, 6 Mar 2016 20:49:34 +0100 Subject: [PATCH] Make sure that 'vec' is up-to-date.
of we call
binbuf_resize()the address of the atom-vector might change (even if we shrink), so we need to update the 'vec' variable that's caching this address.
src/x_text.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/src/x_text.c b/src/x_text.c index 4b25983..eed93a5 100644 --- a/src/x_text.c +++ b/src/x_text.c @@ -706,6 +706,7 @@ static void text_set_list(t_text_set *x, sizeof(*vec) * (oldn - end)); if (n < oldn) (void)binbuf_resize(b, n);
vec = binbuf_getvec(b); } } else-- 2.7.0
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list