# How to trace Maxima failures

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();
...       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 close merge delete

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

( 2017-07-14 23:40:22 +0200 )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.

( 2017-07-20 01:24:28 +0200 )edit

Sort by » oldest newest most voted

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)")
....:          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.

more

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();
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.]

( 2017-07-23 23:50:44 +0200 )edit

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

( 2017-07-24 17:22:18 +0200 )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.

( 2017-07-25 10:46:58 +0200 )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]

( 2017-07-25 11:38:28 +0200 )edit