all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: 17168@debbugs.gnu.org
Subject: bug#17168: 24.3.50; Segfault at mark_object
Date: Thu, 03 Apr 2014 11:42:54 -0400	[thread overview]
Message-ID: <jwvr45etote.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <533D6A19.8050504@yandex.ru> (Dmitry Antipov's message of "Thu, 03 Apr 2014 18:03:05 +0400")

> What about this workaround? Until we find a better solution,
> this should prevent crashes at least.

Let's try to find a better fix instead of another workaround around the
existing workaround.

So the existing workaround is here:

	    /* Check if the symbol was created during loadup.  In such a case
	       it might be pointed to by pure bytecode which we don't trace,
	       so we conservatively assume that it is live.  */
	    bool pure_p = PURE_POINTER_P (XSTRING (sym->s.name));

	    if (!sym->s.gcmarkbit && !pure_p)
	      {
		if (sym->s.redirect == SYMBOL_LOCALIZED)
		  xfree (SYMBOL_BLV (&sym->s));
		sym->s.next = symbol_free_list;
		symbol_free_list = &sym->s;
#if GC_MARK_STACK
		symbol_free_list->function = Vdead;
#endif
		++this_free;
	      }
	    else
	      {
		++num_used;
		if (!pure_p)
		  eassert (!STRING_MARKED_P (XSTRING (sym->s.name)));
		sym->s.gcmarkbit = 0;
	      }

I.e. any symbol with a pure name is assumed to be potentially reachable
from some pure objects.  But not only this assumption is wrong, but its
implementation is wrong as well: we just keep the symbol without making
sure we also keep the objects it points to.

Furthermore, in theory some pure object may very well point to a symbol
whose name was not made pure.  Worse, a pure object may point to several
other kinds of non-pure objects, so this special treatment we have for
symbols should really be applied to other "non-purifyable" objects.

How 'bout we change `purecopy' such that before doing

    /* Not purified, don't hash-cons.  */
    return obj;

it adds the object to a table of "objects pointed from pure space"?

This table should probably be a hash-table (for simplicity), and of
course we'd only add objects to it when the purecopy call was
a recursive call, not for toplevel calls (i.e. calling (purecopy
<process>) should not add <process> to the table since it's not pointed
to from a pure object, whereas (purecopy '(<process>)) should).


        Stefan





  reply	other threads:[~2014-04-03 15:42 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-02  7:44 bug#17168: 24.3.50; Segfault at mark_object Nicolas Richard
2014-04-02 15:53 ` Daniel Colascione
2014-04-02 17:59   ` Nicolas Richard
2014-04-02 16:29 ` Dmitry Antipov
2014-04-02 19:46   ` Daniel Colascione
2014-04-02 20:33     ` Daniel Colascione
2014-04-02 20:57       ` Nicolas Richard
2014-04-02 21:50         ` Daniel Colascione
2014-04-02 23:24           ` Stefan Monnier
2014-04-03  0:28             ` Daniel Colascione
2014-04-02 20:37     ` Eli Zaretskii
2014-04-02 20:40       ` Daniel Colascione
2014-04-02 20:55         ` Eli Zaretskii
2014-04-03  6:59         ` Dmitry Antipov
2014-04-03  7:04           ` Dmitry Antipov
2014-04-03  7:55             ` Daniel Colascione
2014-04-03  9:08               ` Daniel Colascione
2014-04-03 14:03                 ` Dmitry Antipov
2014-04-03 15:42                   ` Stefan Monnier [this message]
2014-04-03 16:47                     ` Daniel Colascione
2014-04-03 17:49                       ` Dmitry Antipov
2014-04-03 17:51                         ` Daniel Colascione
2014-04-03 19:21                           ` Stefan Monnier
2014-04-03 19:22                             ` Daniel Colascione
2014-04-05 22:37                               ` Daniel Colascione
2014-04-06  5:05                                 ` Dmitry Antipov
2014-04-06  5:11                                   ` Daniel Colascione
2014-04-06 18:00                                     ` Richard Stallman
2014-04-06 18:10                                       ` Daniel Colascione
2014-04-06 19:06                                         ` Eli Zaretskii
2014-04-07  7:49                                         ` martin rudalics
2014-04-07  8:18                                           ` Dmitry Antipov
2014-04-07  9:20                                             ` martin rudalics
2014-04-06 12:36                                 ` Stefan Monnier
2014-04-06 15:06                                   ` Eli Zaretskii
2014-04-06 15:59                                     ` Daniel Colascione
2014-04-06 16:19                                       ` Eli Zaretskii
2014-04-06 16:24                                         ` Daniel Colascione
2014-04-06 16:29                                           ` Eli Zaretskii
2014-04-06 16:37                                             ` Daniel Colascione
2014-04-06 16:59                                               ` Eli Zaretskii
2014-04-06 17:11                                                 ` Daniel Colascione
2014-04-06 19:44                                                 ` Stefan Monnier
2014-04-06 19:42                                     ` Stefan Monnier
2014-04-06 15:46                                   ` Daniel Colascione
2014-04-06 19:58                                     ` Stefan Monnier
2014-04-06 20:13                                       ` Daniel Colascione
2014-04-06 20:53                                         ` Daniel Colascione
2014-04-06 21:08                                         ` Stefan Monnier
2014-04-06 21:37                                           ` Daniel Colascione
2014-04-07 16:28                                             ` Stefan Monnier
2014-04-07 19:06                                               ` Daniel Colascione
2014-04-07 20:42                                                 ` Stefan Monnier
2014-04-08  7:14                                                 ` martin rudalics
2014-04-08  8:47                                                   ` Daniel Colascione
2014-04-06 18:01                                   ` Richard Stallman
2014-04-06 19:58                                     ` Stefan Monnier
2014-04-07 16:56                                       ` Richard Stallman
2014-04-02 20:49     ` Nicolas Richard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvr45etote.fsf-monnier+emacsbugs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=17168@debbugs.gnu.org \
    --cc=dmantipov@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.