[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 <dancol@dancol.org>
>> CC: dmantipov@yandex.ru, 17168@debbugs.gnu.org
>>
>>> 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?
signature.asc
Description: OpenPGP digital signature
- bug#17168: 24.3.50; Segfault at mark_object, (continued)
- bug#17168: 24.3.50; Segfault at mark_object, Richard Stallman, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Daniel Colascione, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Eli Zaretskii, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, martin rudalics, 2014/04/07
- bug#17168: 24.3.50; Segfault at mark_object, Dmitry Antipov, 2014/04/07
- bug#17168: 24.3.50; Segfault at mark_object, martin rudalics, 2014/04/07
- bug#17168: 24.3.50; Segfault at mark_object, Stefan Monnier, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Eli Zaretskii, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Daniel Colascione, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Eli Zaretskii, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object,
Daniel Colascione <=
- bug#17168: 24.3.50; Segfault at mark_object, Eli Zaretskii, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Daniel Colascione, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Eli Zaretskii, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Daniel Colascione, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Stefan Monnier, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Stefan Monnier, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Daniel Colascione, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Stefan Monnier, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Daniel Colascione, 2014/04/06
- bug#17168: 24.3.50; Segfault at mark_object, Daniel Colascione, 2014/04/06