[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:24:01 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 04/06/2014 09:19 AM, Eli Zaretskii wrote:
>> Date: Sun, 06 Apr 2014 08:59:55 -0700
>> From: Daniel Colascione <address@hidden>
>> CC: address@hidden, address@hidden
>>> As an alternative, would it make sense to try to understand why the
>>> problems started when they did?  IOW, how come we never saw this until
>>> now?
>> Who knows? The problem arises we happen to form a pointer on the stack
>> to an undead symbol, and *any* code change could be responsible for our
>> doing that more frequently. I don't see you can blame it on 114156.
> 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?

>>> 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.

> 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?

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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