unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#15688: Changes that should go into version 24.4
       [not found]       ` <83ob0y4mdk.fsf@gnu.org>
@ 2014-03-22 14:03         ` Stefan
  2014-03-22 14:53           ` Eli Zaretskii
  2014-03-22 23:57           ` Richard Stallman
  0 siblings, 2 replies; 3+ messages in thread
From: Stefan @ 2014-03-22 14:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rms, 15688

> Not sure if those are related, but if they aren't, how can we explain
> that only Richard experiences these problems?

My guess is that they only show up on Yeeloong, or maybe mips.
Could even be a compiler bug, for all I know.

> In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15688#107, Stefan
> described some insight on the problem, and Richard suggested that
> someone writes debugging code to detect the situation that apparently
> is a precursor to the crash.  No one wrote such a code, AFAIK; perhaps
> we should.  (I don't understand what Stefan said enough to do this,
> but maybe someone else does.)

I'm not sure what kind of code could catch this, nor when to run it.


        Stefan





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#15688: Changes that should go into version 24.4
  2014-03-22 14:03         ` bug#15688: Changes that should go into version 24.4 Stefan
@ 2014-03-22 14:53           ` Eli Zaretskii
  2014-03-22 23:57           ` Richard Stallman
  1 sibling, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2014-03-22 14:53 UTC (permalink / raw)
  To: Stefan; +Cc: rms, 15688

> From: Stefan <monnier@iro.umontreal.ca>
> Cc: Daniel Colascione <dancol@dancol.org>,  rms@gnu.org,  15688@debbugs.gnu.org
> Date: Sat, 22 Mar 2014 10:03:09 -0400
> 
> > Not sure if those are related, but if they aren't, how can we explain
> > that only Richard experiences these problems?
> 
> My guess is that they only show up on Yeeloong, or maybe mips.
> Could even be a compiler bug, for all I know.

Could be.  But we have quite a few GC-related bug reports lately, so
it's not inconceivable that they are related.

> > In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15688#107, Stefan
> > described some insight on the problem, and Richard suggested that
> > someone writes debugging code to detect the situation that apparently
> > is a precursor to the crash.  No one wrote such a code, AFAIK; perhaps
> > we should.  (I don't understand what Stefan said enough to do this,
> > but maybe someone else does.)
> 
> I'm not sure what kind of code could catch this, nor when to run it.

Perhaps you could add more detail to what you said there, and then
others could try thinking about what kind of code would help.





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#15688: Changes that should go into version 24.4
  2014-03-22 14:03         ` bug#15688: Changes that should go into version 24.4 Stefan
  2014-03-22 14:53           ` Eli Zaretskii
@ 2014-03-22 23:57           ` Richard Stallman
  1 sibling, 0 replies; 3+ messages in thread
From: Richard Stallman @ 2014-03-22 23:57 UTC (permalink / raw)
  To: Stefan; +Cc: 15688

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    My guess is that they only show up on Yeeloong, or maybe mips.
    Could even be a compiler bug, for all I know.

Since I can't get any more data by debugging when it crashes, what
good do you think will be done by leaving out the workaround I
installed?  If you don't want it in the trunk and the release, I won't
override you, but I will install it in my own copy.  I'm tired of
the hassle and I see nothing to be gained by suffering it more.

    > In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15688#107, Stefan
    > described some insight on the problem, and Richard suggested that
    > someone writes debugging code to detect the situation that apparently
    > is a precursor to the crash.  No one wrote such a code, AFAIK; perhaps
    > we should.  (I don't understand what Stefan said enough to do this,
    > but maybe someone else does.)

    I'm not sure what kind of code could catch this, nor when to run it.

Here's one idea: store that vector somewhere where GC can see it, and
arrange to abort on freeing that vector.  By debugging at that point
we might learn some more.

That seems easy enough that I will try it one of these days.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.






^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-03-22 23:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <E1WRB2J-0001lO-VA@fencepost.gnu.org>
     [not found] ` <532CEDEF.90707@dancol.org>
     [not found]   ` <83r45u4o6s.fsf@gnu.org>
     [not found]     ` <532D4ECF.5040905@dancol.org>
     [not found]       ` <83ob0y4mdk.fsf@gnu.org>
2014-03-22 14:03         ` bug#15688: Changes that should go into version 24.4 Stefan
2014-03-22 14:53           ` Eli Zaretskii
2014-03-22 23:57           ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).