[Top][All Lists]

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

Re: Thread-unsafe initialization problems in Guile

From: Mark H Weaver
Subject: Re: Thread-unsafe initialization problems in Guile
Date: Thu, 29 Nov 2012 17:42:07 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>> It would be good to fix these before 2.0.7 is released, but I'm a bit
>> uncertain of how best to do so, and I don't have time at the moment.
>> ./posix.c:1375:            make_rw_port = scm_c_private_variable ("ice-9 
>> popen",
>> ./debug.c:217:    local_eval_var = scm_c_public_variable ("ice-9 
>> local-eval", "local-eval");
>> ./strports.c:541:      eval_string = scm_c_public_lookup ("ice-9 
>> eval-string", "eval-string");
> I’m actually not sure what you mean here.

Those are three bugs where a global static variable is lazily
initialized in a way that is not thread-safe.  The one in strports.c
actually caused a reproducible crash bug for a user who created multiple
threads, each of which called scm_eval_string.

Consider the bug in scm_local_eval, which I'm ashamed to say was written
by me before I educated myself on weakly-ordered memory models:

scm_local_eval (SCM exp, SCM env)
  static SCM local_eval_var = SCM_BOOL_F;

  if (scm_is_false (local_eval_var))
    local_eval_var = scm_c_public_variable ("ice-9 local-eval", "local-eval");

  return scm_call_2 (SCM_VARIABLE_REF (local_eval_var), exp, env);

The problem is that it's possible for a thread to see a non-#f value for
'local_eval_var' before it sees the memory it points to properly

> Anyway, I think we ought to release 2.0.7 now.  And yes, there will be a
> 2.0.8 with a number of additional fixes.  :-)

Okay, that's fine.  We can fix these for 2.0.8.


reply via email to

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