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