From: Bart Schaefer <schaefer@brasslantern.com> To: "Johan Ström" <johan@stromnet.se> Cc: Jun T <takimoto-j@kba.biglobe.ne.jp>, Zsh hackers list <zsh-workers@zsh.org> Subject: Re: 5.9 core dumps under zleentry->zleread->zlecore Date: Sat, 4 Jun 2022 13:06:39 -0700 [thread overview] Message-ID: <CAH+w=7akr+BoyGJRTG30UWpuE9iHh_Tc4QmubMCJMFT-VRYXpg@mail.gmail.com> (raw) In-Reply-To: <54c2c561-a3dc-5710-d6b6-6e235a6396b8@stromnet.se> On Sat, Jun 4, 2022 at 12:39 AM Johan Ström <johan@stromnet.se> wrote: > > Hm, I had cases where terminals have been on the same virtual desktop, > with no re-arranging going on at the moment, or since last being used > (basically only resuming work in existing windows). > Not sure if SIGWINCH would be sent by just switching virtual desktop (sway). One reason I'm speculating about this is because of this from your previous stack trace: #9 0x000055ff7ab040f8 zalloc (zsh + 0x730f8) #10 0x00007fb08a549417 calclist (complete.so + 0x1b417) #11 0x00007fb08a54b040 ilistmatches (complete.so + 0x1d040) There's only one zalloc() in calclist: ws = g->widths = (int *) zalloc(zterm_columns * sizeof(int)); If zterm_columns has somehow become messed up, this might run you out of memory. Then in the other trace you have: #10 0x000055d4aa005493 zhandler (zsh + 0xa8493) #11 0x00007f2f935388e0 n/a (libc.so.6 + 0x3e8e0) #12 0x00007f2f935fbef2 read (libc.so.6 + 0x101ef2) That definitely means a signal was received, and SIGWINCH is explicitly unblocked around that read() call, but it goes straight on to: #9 0x000055d4a9fc3874 zleentry (zsh + 0x66874) The only way to get to that from a signal handler is when a user-defined trap is run: /* * If zle was running while the trap was executed, see if we * need to restore the display. */ if (zleactive && resetneeded) zleentry(ZLE_CMD_REFRESH); However (I suspect) the compiler has optimized out a couple of intervening function calls, which is why I hope you can get this to reoccur with a debug build. > In /etc/zsh, only zprofile: > https://github.com/archlinux/svntogit-packages/blob/packages/zsh/trunk/zprofile > Which references this: > https://github.com/archlinux/svntogit-packages/blob/packages/filesystem/trunk/profile Yes, which does emulate sh -c 'source /etc/profile' though it seems unlikely that anything too weird is coming in that way.
prev parent reply other threads:[~2022-06-04 20:07 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-06-02 7:11 Johan Ström 2022-06-02 7:31 ` Bart Schaefer 2022-06-02 9:25 ` Johan Ström 2022-06-03 7:14 ` Jun T 2022-06-03 7:19 ` Johan Ström 2022-06-03 9:53 ` Jun T 2022-06-03 10:02 ` Johan Ström 2022-06-04 3:32 ` Bart Schaefer 2022-06-04 7:39 ` Johan Ström 2022-06-04 20:06 ` Bart Schaefer [this message]
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='CAH+w=7akr+BoyGJRTG30UWpuE9iHh_Tc4QmubMCJMFT-VRYXpg@mail.gmail.com' \ --to=schaefer@brasslantern.com \ --cc=johan@stromnet.se \ --cc=takimoto-j@kba.biglobe.ne.jp \ --cc=zsh-workers@zsh.org \ --subject='Re: 5.9 core dumps under zleentry->zleread->zlecore' \ /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
Code repositories for project(s) associated with this 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).