Ask Your Question
0

How to trace Maxima failures

asked 2017-07-14 14:37:51 -0600

Richard_L gravatar image

updated 2017-07-20 17:11:43 -0600

I often hit the "Detected access to protected memory ..." failure from maxima. In some cases it seems to go into a loop whereupon I receive the same message hundreds of times. I know which sage worksheet cell is failing, but cannot find what it is about that cell which causes the failure, because maxima does not tell me. Is it possible to set up the worksheet so that this error is trapped and triggers a stack trace in sage/python?

sage: version()  
'SageMath version 7.6, Release Date: 2017-03-25'  
sage: Parallelism().set(nproc=2)  
sage: var('rho12,rho13,rho23', domain='real')  
sage: assume(rho12>0, rho13>0, rho23>0)  
sage: var('r12,r13,r23', domain='real')  
sage: var('m1 m2 m3', domain='real')  
sage: var('mu12,mu13,mu23', domain='real')

sage: ####  
sage: #assume(m1>0, m2>0, m3>0)  # !! This is a Maxima killer (even though physically required)! 
sage: m1=1; m2=1; m3=1     
sage: # !! With 'assume' above and with ANY m1,m2,m3 in SR, we seg-fault and core-dump when computing the connection.  
sage: ####  

sage: mu12 = (m1*m2)/(m1+m2); mu23 = (m2*m3)/(m2+m3); mu13 = (m1*m3)/(m1+m3)  
sage: # Contravariant metric tensor, per Turbiner et al., arXiv:1611.08157.  
sage: Ginv = matrix([[2/mu12*rho12, 1/m1*(rho12+rho13-rho23), 1/m2*(rho12+rho23-rho13)],\  
...           [1/m1*(rho12+rho13-rho23), 2/mu13*rho13, 1/m3*(rho13+rho23-rho12)],\  
...           [1/m2*(rho12+rho23-rho13), 1/m3*(rho13+rho23-rho12), 2/mu23*rho23]])  
sage: G = Ginv.inverse();  
sage: # Begin manifold creation  
sage: M = Manifold(1*3,'R^3',field='real',start_index=1)  
sage: U = M.open_subset('U')  
sage: Rho.<rho12,rho13,rho23> = U.chart();  
sage: Rho.add_restrictions([rho12>0, rho13>0, rho23>0])  
sage: Rho.add_restrictions([sqrt(rho23)<sqrt(rho12)+sqrt(rho13),\  
...       sqrt(rho13)<sqrt(rho12)+sqrt(rho23), sqrt(rho12)<sqrt(rho13)+sqrt(rho23)])  
...  
sage: g = M.riemannian_metric('g');  
sage: g[:] = G[:].simplify_full()  
sage: ginv = g.inverse()  

sage: ### This will seg-fault and core-dump if ANY m1,m2,m3 are in SR, and the 'assume' statement active.  
sage: nabla = g.connection()

sage: # Turbiner calculates the Ricci scalar.  
sage: ### Attempting to do so here causes seg fault if all m1,m2,m3=1!   
sage: #  (Is this because of singularities at all boundaries of rho-space? 
sage: # (Regardless, code should *never* crash.)  
sage: Ric_g = g.ricci_scalar()
edit retag flag offensive close merge delete

Comments

could you provide a minimal code snippet that triggers the error?

vdelecroix gravatar imagevdelecroix ( 2017-07-14 16:40:22 -0600 )edit

Correction: Wait long enough and it eventually dumps core. The dump is huge, 16 GB, even though the pgm is probably not using all that. Unfortunately, I don't have all the debugging libraries installed, so gdb can only tell me what we already know, that the seg-fault occurred in the ecl library. The shortest snippet I can make is ~40 lines. Notice that two seg-faults are possible from this code, depending on which lines are (un)commented.

Richard_L gravatar imageRichard_L ( 2017-07-19 18:24:28 -0600 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2017-07-23 04:44:45 -0600

eric_g gravatar image

This is not an answer to the main question (How to trace Maxima failures?) but to the issue raised at the end of the code snippet:

sage: # Turbiner calculates the Ricci scalar.  
sage: ### Attempting to do so here causes seg fault if all m1,m2,m3=1!

The following slightly simplified version of your code does compute the Ricci scalar without any seg. fault for me:

sage: version()
'SageMath version 8.0, Release Date: 2017-07-21'
sage: Parallelism().set(nproc=4)
sage: M = Manifold(3, 'R^3', start_index=1)
sage: U = M.open_subset('U')
sage: Rho.<rho12,rho13,rho23> = U.chart("rho12:(0,+oo) rho13:(0,+oo) rho23:(0,+oo)")
sage: Rho.add_restrictions([sqrt(rho23)<sqrt(rho12)+sqrt(rho13),
....:          sqrt(rho13)<sqrt(rho12)+sqrt(rho23), sqrt(rho12)<sqrt(rho13)+sqrt(rho23)])
sage: var('m1 m2 m3', domain='real')
sage: # assume(m1>0, m2>0, m3>0)  # uncommenting and commenting the next line triggers a seg fault 
sage: m1=1; m2=1; m3=1  # commenting and uncommenting the previous line triggers a seg fault 
sage: mu12 = (m1*m2)/(m1+m2); mu23 = (m2*m3)/(m2+m3); mu13 = (m1*m3)/(m1+m3)
sage: Ginv = matrix([[2/mu12*rho12, 1/m1*(rho12+rho13-rho23), 1/m2*(rho12+rho23-rho13)],
....:  [1/m1*(rho12+rho13-rho23), 2/mu13*rho13, 1/m3*(rho13+rho23-rho12)],
....:  [1/m2*(rho12+rho23-rho13), 1/m3*(rho13+rho23-rho12), 2/mu23*rho23]])
sage: G = Ginv.inverse()
sage: g = M.riemannian_metric('g')
sage: g[:] = G[:].simplify_full()
sage: nabla = g.connection()
sage: Ric_g = g.ricci_scalar(); Ric_g
Scalar field r(g) on the 3-dimensional differentiable manifold R^3

As a test, we may check that the inverse metric coincides with that of Eq. (15) of Turbiner et al. arXiv:1611.08157:

sage: g.inverse()[:]
[               4*rho12  rho12 + rho13 - rho23  rho12 - rho13 + rho23]
[ rho12 + rho13 - rho23                4*rho13 -rho12 + rho13 + rho23]
[ rho12 - rho13 + rho23 -rho12 + rho13 + rho23                4*rho23]

However, the expression of the Ricci scalar is simpler than that found by Turbiner et al., as given between Eqs. (31) and (32) of their paper:

sage: Ric_g.expr()
9/(rho12 + rho13 + rho23)

maybe because Turbiner et al. are considering $r_{ij} = \sqrt{\rho_{ij}}$ as variables?

Besides, I confirm the segmentation fault in the Maxima part of the computation of the connection when assume(m1>0, m2>0, m3>0) is effective.

edit flag offensive delete link more

Comments

Thanks. Is the essence of your changes replacing
sage: var('rho12,rho13,rho23', domain='real')
sage: assume(rho12>0, rho13>0, rho23>0)
and
sage: Rho.<rho12,rho13,rho23> = U.chart();
sage: Rho.add_restrictions([rho12>0, rho13>0, rho23>0])
with sage: Rho.<rho12,rho13,rho23> = U.chart("rho12:(0,+oo) rho13:(0,+oo) rho23:(0,+oo)") ?

[As to the Ricci scalar, I cannot see how the manner in which we get to the rho_ij coordinate system would matter. OTOH, I am puzzled by Turbiner et al.'s detour involving a gauge transformation. As far as I know, the gauge does not alter the metric tensor on which the Ricci scalar depends.]

Richard_L gravatar imageRichard_L ( 2017-07-23 16:50:44 -0600 )edit

The new code still fails in computing the Ricci scalar in Sage 7.6. I confirm correct behavior in Sage 8.0.

Richard_L gravatar imageRichard_L ( 2017-07-24 10:22:18 -0600 )edit

I had not realized this but I confirm: on my computer too, the new code triggers a seg fault in Maxima while computing the Ricci scalar with Sage 7.6. However, it is OK with both Sage 7.5.1 and Sage 8.0.

eric_g gravatar imageeric_g ( 2017-07-25 03:46:58 -0600 )edit

Answering your question "Is the essence...": yes; using assumptions(), you can check that declaring (0, +oo) as the range of coordinate x causes assume(x>0):

sage: M = Manifold(3, 'R^3', start_index=1)
sage: U = M.open_subset('U')
sage: Rho.<rho12,rho13,rho23> = U.chart("rho12:(0,+oo) rho13:(0,+oo) rho23:(0,+oo)")
sage: assumptions()
[rho12 is real, rho12 > 0, rho13 is real, rho13 > 0, rho23 is real, rho23 > 0]
eric_g gravatar imageeric_g ( 2017-07-25 04:38:28 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2017-07-14 14:37:51 -0600

Seen: 83 times

Last updated: Jul 23