On 04/06/2014 09:29 AM, Eli Zaretskii wrote: >> Date: Sun, 06 Apr 2014 09:24:01 -0700 >> From: Daniel Colascione >> CC: monnier@IRO.UMontreal.CA, dmantipov@yandex.ru, 17168@debbugs.gnu.org >> >>> Then how do you explain that we never saw such problems, in all the >>> years before? >> >> It's probabilistic. How do you know we didn't? > > Because Richard has been using that machine for years, and I very much > doubt that he changed his usage patterns lately. Richard's not the only one who has seen this crash. Drew's also reported GC crashes in odd, and different, places. >>>>> In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15583#23, Richard >>>>> provided the last good revno (113938) and the first bad one (114268); >>>>> I looked at that range of revisions, and 114156 looks relevant. How >>>>> about if we revert it and see if the problems go away? >>>> >>>> The bug would still be there, and we'd have no way to tell whether your >>>> proposed change actually reduced its occurrence to a tolerable level. >>>> Why would you want to do that instead of just fixing the bug? >>> >>> Because it's simpler, >> >> It's easy to make code that's simple and wrong. > > I didn't suggest any new code. No: you're just suggesting leaving incorrect code in Emacs. >>> and because it just might be that the bug was >>> caused by that other changeset. >> >> How might that changeset in particular have caused the problem reports? > > It is related to calling a function, and is in the same function from > which all the recent crashes started. You haven't identified a causal mechanism. Any recent change could have caused enough of a shift in code generation or stack layout to cause this problem, and because it manifests so seldom, it'd be hard to verify that reverting any particular change "fixed" the problem. Also, eval_sub does *everything*. It's no surprise that we saw the crashes there. That's like saying "all crashes are associated with main, this change affects main, and therefore this change is responsible."