#9583: Unhandled SIGSEGV with 4.5.2.alpha0 on t2
-----------------------+----------------------------------------------------
   Reporter:  mpatel   |       Owner:  drkirkby  
       Type:  defect   |      Status:  new       
   Priority:  blocker  |   Milestone:  sage-4.5.2
  Component:  solaris  |    Keywords:            
     Author:           |    Upstream:  N/A       
   Reviewer:           |      Merged:            
Work_issues:           |  
-----------------------+----------------------------------------------------

Comment(by SimonKing):

 Hi!

 Replying to [comment:3 mpatel]:
 > Bisection indicates that #1396 is the source of the problem:

 Then I think I should explain what portion of that patch I think might be
 related, and my reasons for writing it.

 As David find out using {{{sage -gdb}}}, the segfault occurs in
 {{{sage.libs.singular.option.LibSingularOptions_abstract.load}}}, and the
 C-code in the traceback suggests that it is exactly in line 286 of the
 Cython file,
 {{{
 Kstd1_mu  = value[2]
 }}}

 What happens at startup?

 In line 666 of option.pyx, some {{{LibSingularOptions}}} object is
 created, and in line 667, the method {{{reset_default()}}} is called.
 There, we have
 {{{
     from sage.libs.singular.singular import _saved_options
     self.load(_saved_options)
 }}}

 Where does _saved_options come from?

 _saved_options is defined in line 51 of sage/libs/singular/singular.pyx.
 It is immediately initialised with some value, which I explicitly did in
 order to ''prevent'' a segfault caused by accessing an uninitialised
 C-variable. But the true initialisation (with the actual value used by
 libsingular) is then done at line 675.

 In particular, {{{value[2]}}} in the segfaulting line should be
 initialised to the value 0. So, I don't see why it should be a problem to
 assign this to the int variable {{{Kstd1_mu}}}.

 I am not familiar with t2, and I don't know whether I would be able to
 build sage on it (I don't even know if I have an account). So, could you
 please test (by adding print commands in the appropriate places or so):

  1. Is _save_value indeed initialised in line 51 of
 sage/libs/singular/singular.pyx?
  2. Is the true initialisation in line 675 of
 sage/libs/singular/singular.pyx executed?
  3. What is the argument of the {{{load}}} function right before it
 segfaults? It should be a list of three int, the last two being zero.
  4. Could it be that I simply forgot to say {{{global _saved_options}}}
 before line 51 of sage/libs/singular/singular.pyx?

 Cheers,
 Simon

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9583#comment:13>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to