Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: access already freed memory when resize window
- X-seq: zsh-workers 38196
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: access already freed memory when resize window
- Date: Mon, 21 Mar 2016 08:10:31 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=7ALrzFKcai5ZICq4zAJSZuixnUWRSU3z6i7rgfMBP5U=; b=OTTgx0Rgz8YMQP5MiER8a0l55hgkc0XeP4S2c0X4zhoMXNZnMxDkc/Wkc5LQZmN8OJ oTyxTBVgek0Anzjmbtlh+LezcKln01t0+E0MAmp7NMTI1TiJ55aajuASKnSOWBtrfjT4 8gPzp0W7fF7SnKdiKvgEgtZME9Xmr7eIhFzeT0k6z+lX+3qTjofVQ8ErEr2uPt6trOuP xeRQRPcgLc+97UpeWRxvMrlBqQ08deuA017G+PrzvhTxbbxFyZ/Q+OgCb7fusrvoe7c3 yNgSFxo4TuSyYKd47ghe4mJjNxRoXEEjFB6NlhlOvmQDE3DdniYCYioPGfIuZ4gVkX83 gGLg==
- In-reply-to: <20160321104301.0ff32aae@pwslap01u.europe.root.pri>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAKzW8okOFzO=ZNdi4HkKuQDnDdqAkQELmXGYJ3XSoho_kvJNzw@mail.gmail.com> <160320101910.ZM8306@torch.brasslantern.com> <20160321104301.0ff32aae@pwslap01u.europe.root.pri>
On Mar 21, 10:43am, Peter Stephenson wrote:
} Subject: Re: access already freed memory when resize window
}
} On Sun, 20 Mar 2016 10:19:10 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > It doesn't even help to queue signals, because waiting for the command
} > substitution to finish must temporarily unqueue them.
}
} Right, but shouldn't there at least be some attempt to tame the points
} at which recursion can happen? Or is that already happening, and all
} the effects we're seeing are out at the top level after the signal
} handler has returned?
Generically, the problem is that reexpandprompt() was doing
free(GlobalPointer);
GlobalPointer = maybe_reference_GlobalPointer();
The fact that the reference is from a signal handler is an instantiation
of "maybe". So at the very least we have to change the order of the
function call and the free.
An added complication is that we have two interdependent global pointers
that were both being treated that way.
To "tame the recursion" we could do something like this:
#ifdef SIGWINCH
case SIGWINCH:
+ winch_block();
adjustwinsize(1); /* check window size and adjust */
(void) handletrap(SIGWINCH);
+ winch_unblock();
break;
#endif
But then we might stop adjusting our idea of the window size before the
user stops resizing the window. (Also due to the way we manage signal
queuing we don't know the current state of winch_block() at that point,
so it might not be correct to block/unblock. The whole winch-handling
scheme would have to be revised to be more like queue_signals().)
Messages sorted by:
Reverse Date,
Date,
Thread,
Author