From: "Daniel Shahaf" <d.s@daniel.shahaf.name>
To: "Peter Stephenson" <p.stephenson@samsung.com>
Cc: zsh-users@zsh.org, "Dennis Schwartz" <dennis.schwartz@protonmail.com>
Subject: Re: TRAPINT doesn't work reliably
Date: Fri, 27 Sep 2019 13:43:14 +0000 [thread overview]
Message-ID: <c2acffef-b127-42b8-be46-45a53477f8ba@www.fastmail.com> (raw)
In-Reply-To: <1569511631.3770.8.camel@samsung.com>
Peter Stephenson wrote on Thu, 26 Sep 2019 15:27 +00:00:
> On Wed, 2019-09-25 at 18:46 +0000, Daniel Shahaf wrote:
> > Peter Stephenson wrote on Wed, Sep 25, 2019 at 18:04:45 +0100:
> > >
> > > On Wed, 2019-09-25 at 16:25 +0000, Dennis Schwartz wrote:
> > > >
> > > > I haven't tried compiling from the latest source code yet. If this is
> > > > desired I could try this again at a later point in time.
> > > I suspect that's going to have to be the next step, if you get the
> > > chance. In the top-level directory, run configure as
> > >
> > > ./configure --enable-zsh-debug
> > >
> > Should Dennis use any of these flags as well? —
>
> It's not clear anything else is going to help debugging, certainly
> if the build that's showing the problem was made (as almost all
> distro builds are made) using the system allocators. In that
> case none of the zsh memory specials apply,
Even without any special configure flags, there's still zhalloc(). The source
of zhalloc() contains some blocks conditional on --enable-zsh-valgrind.
I assume passing that configure flag will let valgrind detect use-after-freeheap()
bugs.
Also, I thought --enable-zsh-secure-free and --enable-zsh-heap-debug were
independent of --enable-zsh-mem*.
> and if we turn on zsh memory management we are in a different world
> --- which might shows the problem but could well perturb it somewhere
> completely different.
Sure, any change could make the symptoms disappear, particularly
switching to a different allocator.
Cheers,
Daniel
next prev parent reply other threads:[~2019-09-27 13:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190917164905epcas1p4ad458ffcd504501780d522880c81de3e@epcas1p4.samsung.com>
2019-09-17 16:47 ` Dennis Schwartz
2019-09-24 8:44 ` Peter Stephenson
2019-09-25 13:02 ` Dennis Schwartz
2019-09-25 14:01 ` Peter Stephenson
2019-09-25 16:25 ` Dennis Schwartz
2019-09-25 17:04 ` Peter Stephenson
2019-09-25 18:46 ` Daniel Shahaf
2019-09-26 15:27 ` Peter Stephenson
2019-09-27 13:43 ` Daniel Shahaf [this message]
2019-09-25 17:56 ` Peter Stephenson
2019-09-26 14:48 ` Dennis Schwartz
2019-09-26 15:25 ` Peter Stephenson
2019-09-26 17:10 ` Dennis Schwartz
2019-09-27 13:46 ` Daniel Shahaf
2019-09-28 11:16 ` Dennis Schwartz
2019-09-28 14:29 ` Daniel Shahaf
2019-09-28 18:21 ` Dennis Schwartz
2019-09-28 18:58 ` Dennis Schwartz
2019-09-28 16:00 ` Bart Schaefer
2019-09-29 16:54 ` Peter Stephenson
2019-09-27 19:05 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c2acffef-b127-42b8-be46-45a53477f8ba@www.fastmail.com \
--to=d.s@daniel.shahaf.name \
--cc=dennis.schwartz@protonmail.com \
--cc=p.stephenson@samsung.com \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).