From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-36030-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 27712 invoked by alias); 9 Aug 2015 23:42:35 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 36030
Received: (qmail 15554 invoked from network); 9 Aug 2015 23:42:33 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no
	version=3.4.0
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:from:message-id:date:in-reply-to:comments
         :references:to:subject:mime-version:content-type;
        bh=2UhmVpD4ITMqVX5bcAarsVi5RlZhDhanr2nzsPTvfhA=;
        b=KBfRgpAK4YIZcRM0ogVJZOaR9ntOlj3m/aefQ/njWGAzaRC2vM4XFZrtkAySXUGLWJ
         BEMXKQplnuiWC6v4LiBlG4XhijGYR1P1c+5AaTv5I9fY6CV3I5BFbGJayPJULHDGjOwc
         ei2q5jzuDx0ASRnOdF30hEIlyUpISvJUfPLJmhR2Rp1IqK/zCoy/93OZ+9c6DIHl7FnA
         urWezZCSPQF0ivCs7iTJVPAZ8sJh1KiOHd+OEMvnVYeBDKyg5eqjFEw0QmXgJmVmVgrr
         BBoG7Qi8lxhmjXv3ikFVDlE4OBrcvADVjrMORC/6b+Kh5QnSgtWJH6fM/W2NGgufNahy
         CoWQ==
X-Gm-Message-State: ALoCoQlYf6UWvY+y96x+jlqoz/YvIWTh9YnDUvNCDI6m5SgaETdl/yn7hhC1EZcwCqZNwF2z2zdw
X-Received: by 10.60.136.131 with SMTP id qa3mr16697097oeb.34.1439163749334;
        Sun, 09 Aug 2015 16:42:29 -0700 (PDT)
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <150809164225.ZM10049@torch.brasslantern.com>
Date: Sun, 9 Aug 2015 16:42:25 -0700
In-Reply-To: <CA+=GgY4+utmAzyYyBn1wQy1BhFcrzk+DiN+FcqYOpUdrSHhbGg@mail.gmail.com>
Comments: In reply to Mathias Fredriksson <mafredri@gmail.com>
        "Re: Deadlock when receiving kill-signal from child process" (Aug  9,  4:53pm)
References: <CA+=GgY7mHkyK4NJQ6m7y-HpVPKOuKx3-bkJqRHriKzZ662_iwA@mail.gmail.com> 
	<150803085228.ZM24837@torch.brasslantern.com> 
	<CA+=GgY5iZfgUag_V1jqmCv4=PUGBmaV2cNWTDjSO4DAZ+zm-iQ@mail.gmail.com> 
	<150803135818.ZM24977@torch.brasslantern.com> 
	<CA+=GgY7uGzCYEKLBzqrt=ct6q72WFC5w1jMB5RDNe60J-wUz=Q@mail.gmail.com> 
	<150804235400.ZM9958@torch.brasslantern.com> 
	<CA+=GgY5826pmKzn=WHUKCVWOEfRbP=sCN873arRsYHvGgEUb7A@mail.gmail.com> 
	<150805085258.ZM17673@torch.brasslantern.com> 
	<CA+=GgY5F-ZD7us6C6-N+3NevKPmVvcJ+Zm7MYp4yDQTZhxY6kg@mail.gmail.com> 
	<150805115249.ZM7158@torch.brasslantern.com> 
	<CA+=GgY73SZ9NkSS74sOyF_VtaCU=Np8fixq1PbG4QmcgbcfVjQ@mail.gmail.com> 
	<150805132014.ZM7746@torch.brasslantern.com> 
	<CA+=GgY7cg9aDJxN--wcX=+MSD9dd2To3fSm9ecsd=tF1zg=zbQ@mail.gmail.com> 
	<150805220656.ZM18545@torch.brasslantern.com> 
	<CA+=GgY5xEojBVRpKKZp-svZStp-s4=N10Xz2n0=s8SKjUpbNwg@mail.gmail.com> 
	<150806085451.ZM402@torch.brasslantern.com> 
	<CA+=GgY5BAkLceSV_Hav_mhna7M7aTLHH-WqV2EHmDRrMdqi16A@mail.gmail.com> 
	<150806223906.ZM17762@torch.brasslantern.com> 
	<CA+=GgY4+utmAzyYyBn1wQy1BhFcrzk+DiN+FcqYOpUdrSHhbGg@mail.gmail.com>
X-Mailer: OpenZMail Classic (0.9.2 24April2005)
To: zsh-workers@zsh.org
Subject: Re: Deadlock when receiving kill-signal from child process
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Aug 9,  4:53pm, Mathias Fredriksson wrote:
} Subject: Re: Deadlock when receiving kill-signal from child process
}
} I'm wondering if I'm not getting the complete picture
} though since there are some "in ?? ()" also in there (I did build with
} debugging enabled though).

Did you "make install" before running this?  If so, *don't* -- run the
binary straight out of the build tree.  If you "make install" the symbol
table gets stripped even if you've compiled with debugging, which gives
you the incomplete stack traces you've been seeing.

In this case I think that's actually causing a misleading backtrace,
because:

} #17 <signal handler called>
} #18 0x00007fff896db4fe in tiny_free_list_remove_ptr ()
} #19 0x00007fff896d9b2e in szone_free_definite_size ()
} #20 0x0000000105d82ef6 in getredirs ()

There is already a queue_signals() around getredirs() so it should not
be calling a signal handler here, or at least the handler should not
be doing anything interesting.

Also this part doesn't make sense:

} #0  0x00007fff8abf95da in syscall_thread_switch ()
} #1  0x00007fff853a982d in _OSSpinLockLockSlow ()
} #2  0x00007fff896e1635 in szone_force_lock ()
} #3  0x00007fff896e15e6 in _malloc_fork_prepare ()
} #4  0x00007fff82cb8097 in fork ()
} #5  0x0000000105d3f960 in get_match_ret ()
} #6  0x0000000105d45463 in savehistfile ()

There's no call to get_match_ret() from savehistfile(), and it's pretty
unlikely that savehistfile is called at all, so this stack looks trashed
to me.  (My other guess would be you're using the new binary with an old
core file, but theoretically you're not reading a core file at all).

Also here:

} #36 0x0000000105d3d69f in gmatchcmp ()
} #37 0x0000000105d3c6ce in qualisdev ()

qualisdev() doesn't call anything.  Stack definitely hosed.

Nevertheless, it looks like glob.c needs to protect some places where
it manipulates global state.