[Top][All Lists]

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

bug#17168: 24.3.50; Segfault at mark_object

From: Daniel Colascione
Subject: bug#17168: 24.3.50; Segfault at mark_object
Date: Sun, 06 Apr 2014 09:37:23 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 04/06/2014 09:29 AM, Eli Zaretskii wrote:
>> Date: Sun, 06 Apr 2014 09:24:01 -0700
>> From: Daniel Colascione <address@hidden>
>> CC: address@hidden, address@hidden, address@hidden
>>> 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."

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]