Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: zsh crash in recent -current



    Date:        Wed, 13 Mar 2019 10:06:42 +0000
    From:        Chavdar Ivanov <ci4ic4%gmail.com@localhost>
    Message-ID:  <CAG0OUxheb4LzriUoZ_JMoVEZet8BeCcMDEp3pgzryAuusJRhQA%mail.gmail.com@localhost>

  | I saw the one with the trashed history as well.
  |
  | I don't think it is zsh's problem, though. As I mentioned above, I've
  | used v5.7 since it came out without any problems until perhaps 3-4
  | days ago.

I would guess that maybe there is code like this

	for (list_ptr = list_head; list_ptr != NULL; list_ptr = list_ptr->nxt) 
{
		/* do stuff on list */
		if (element_should_be_deleted) {
			/* with testing for NULLs added but not shown here */
			list_ptr->prev->nxt = list_ptr->nxt;
			list_ptr->nxt->prev = list_ptr->prev;
			free(list_ptr);
		}
	}

which will "work" perfectly wih most versions of malloc, as
that free does not change anything in the memory that has been
freed, but will collapse in a giant heap if free() scribbles
over the memory as part of deleting things, which some of the
dumps that various people have shown on this (and similar) issues
looks to be what is happening (the scribbling - it is deliberate
to expose bugs like this one).

Code like the above is easy to write, and most of the time works fine
(and would have worked with the previous malloc) but will die
big time when the arena is scrambled (not just zeroed, usually).

Someone should look for something like this in the areas of zsh
that are crashing, and other programs.

This is far more likely than the new malloc being broken, and just
only happening to hit a few programs, and is more likely than some
random memory corruption that simply has never been noticed until
now.

kre




Home | Main Index | Thread Index | Old Index