Jupyter notebook crashes with multiusers

[jonatha...@googlemail.com]

Dear all,

the jupyter notebook crashes when trying to plot unbounded polyhedra, e.g.:

P = Polyhedron(ieqs=[(0,1,0)])

P.show()

Bounded polyhedra seem to work fine, but also plotting of the face lattice, a FiniteLatticePoset, fails (even for the cube).

The crash appears to be deterministic, but only users other than the owner. (I changed the permissions to 777 inbetween, this does not seem to be the issue.)

This happens on a 9.2. install, but also on a 9.1beta5 install on a different machine (both debian buster).

It does work for prebuilt binaries (9.2 and 9.1).

Here are the system packages picked up:  (* are those that also are picked up for the 9.1beta5 with the same problem).

boost-1_66_0:                                using system package; SPKG will not be installed
boost_cropped-1.66.0.p0:                     using system package; SPKG will not be installed
*bzip2-1.0.6-20150304.p0:                     using system package; SPKG will not be installed
*cmake-3.18.2:                                using system package; SPKG will not be installed
*curl-7.62.0.p0:                              using system package; SPKG will not be installed
*gcc-9.2.0:                                   using system package; SPKG will not be installed
gfan-0.6.2.p1:                               using system package; SPKG will not be installed
*gfortran-9.2.0:                              using system package; SPKG will not be installed
*git-2.11.0:                                  using system package; SPKG will not be installed
*gmp-6.1.2:                                   using system package; SPKG will not be installed
*iconv-1.15:                                  using system package; SPKG will not be installed
*mpfr-4.0.1.p0:                               using system package; SPKG will not be installed
*mpir-3.0.0-644faf502c56f97d9accd301965fc57d6ec70868.p0:using system package; SPKG will not be installed
*ncurses-6.0.p0:                              using system package; SPKG will not be installed
*ninja_build-1.8.2:                           using system package; SPKG will not be installed
pandoc-none:                                 using system package; SPKG will not be installed
*patch-2.7.5:                                 using system package; SPKG will not be installed
*pcre-8.40.p2:                                using system package; SPKG will not be installed
*perl_term_readline_gnu-1.35:                 using system package; SPKG will not be installed
*pkgconf-0.9.7.p2:                            using system package; SPKG will not be installed
*readline-8.0:                                using system package; SPKG will not be installed
*xz-5.2.2.p0:                                 using system package; SPKG will not be installed
*zlib-1.2.11.p0:                              using system package; SPKG will not be installed

Does anyone know what might be the problem?

In the section for installinging sagemath for multiusers there is no hint

https://doc.sagemath.org/html/en/installation/source.html#id11

The full config.log and the crash report are attached.

Thank you,

Jonathan

[François Bissey]

The top of your crash log is interesting, especially with the context you give it.

[I 08:54:47.064 NotebookApp] 302 GET /?token=9646f700a842467835ef92b578ebef632e86a326a85e828b (127.0.0.1) 1.53ms
[I 08:54:56.520 NotebookApp] Kernel started: d273c9d9-80cb-45a6-a336-b3562f294b26, name: sagemath
------------------------------------------------------------------------
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x8bb8)[0x7faa181e6bb8]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0x8c58)[0x7faa181e6c58]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/cysignals/signals.cpython-38-x86_64-linux-gnu.so(+0xc89d)[0x7faa181ea89d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7faa1cb3b730]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7faa1c8107bb]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7faa1c7fb535]
/lib/x86_64-linux-gnu/libgcc_s.so.1(+0x3358)[0x7faa1a2f8358]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/ft2font.cpython-38-x86_64-linux-gnu.so(+0x7a62)[0x7fa87edd6a62]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/ft2font.cpython-38-x86_64-linux-gnu.so(_ZN7FT2FontC1ER13FT_Open_Args_l+0x22b)[0x7fa87edda23b]
/srv/public/shared/DGI-sage/local/lib/python3.8/site-packages/matplotlib/ft2font.cpython-38-x86_64-linux-gnu.so(+0xd35f)[0x7fa87eddc35f]


I’d say it is trying to open a font file to which it has no right.

François

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/48a9b546-c516-4969-b5f2-639964b975e4n%40googlegroups.com.
> <crash.log><config.log>

[jonatha...@googlemail.com]

Thank you François.

I was doubtful that your answer would help, but it did finally after some googling.

I had to run

import matplotlib.font_manager

matplotlib.font_manager._rebuild()

At least on the 9.2 install that did help and once my user had those fonts installed in home (believe this is what happened) then it also fixed it on other machines with the same install, but not with the 9.1beta5. Must be a different problem there.

I hope my solution also works for the students (maybe the fix can also be applied in the jupyter notebook from the start, which would be super nice).

Jonathan

[Dima Pasechnik]

On Fri, Nov 13, 2020 at 11:55 AM 'jonatha...@googlemail.com' via
sage-devel <sage-...@googlegroups.com> wrote:
>
> Thank you François.
>
> I was doubtful that your answer would help, but it did finally after some googling.
>
> I had to run
>
> import matplotlib.font_manager
> matplotlib.font_manager._rebuild()
>
> At least on the 9.2 install that did help and once my user had those fonts installed in home (believe this is what happened) then it also fixed it on other machines with the same install, but not with the 9.1beta5. Must be a different problem there.
>
> I hope my solution also works for the students (maybe the fix can also be applied in the jupyter notebook from the start, which would be super nice).

Calling this every time Sage starts would be a big slowdown, no?
Perhaps only when ~/.sage/ is created, or something like that.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/f76ebb2e-f0c2-4beb-b5fe-a6c90479fb9en%40googlegroups.com.

[jonatha...@googlemail.com]

I only ran it once and it solved it permanently, also for the other installations of the same version on different computers, but with same home-directory. But it appears every user has to call it once.

[Matthias Koeppe]

We have some suspicious code in src/bin/sage-env; perhaps this is a good opportunity to review whether this should be changed.

if [ -z "$MPLCONFIGDIR" ]; then

    # We hardcode a version number in the directory name. The idea is

    # that we keep using the same version number as long as that is

    # possible. Only when some future Matplotlib version really requires

    # a new structure for the $MPLCONFIGDIR should this version

    # number be changed to the new matplotlib version.

    export MPLCONFIGDIR="$DOT_SAGE/matplotlib-1.5.1"

fi

[François Bissey]

Well it certainly wasn’t changed each time we upgraded MPL (and yes I am part
of the guilty) as it should have.

François

[Dima Pasechnik]

On Fri, Nov 13, 2020 at 6:38 PM François Bissey <frp.b...@gmail.com> wrote:
>
> Well it certainly wasn’t changed each time we upgraded MPL (and yes I am part
> of the guilty) as it should have.

Is there a ticket to fix this?
(I frankly don't even see why this was done in the 1st place)

Dima

>
> François
>
> > On 14/11/2020, at 7:05 AM, Matthias Koeppe <matthia...@gmail.com> wrote:
> >
> > We have some suspicious code in src/bin/sage-env; perhaps this is a good opportunity to review whether this should be changed.
> >
> > if [ -z "$MPLCONFIGDIR" ]; then
> > # We hardcode a version number in the directory name. The idea is
> > # that we keep using the same version number as long as that is
> > # possible. Only when some future Matplotlib version really requires
> > # a new structure for the $MPLCONFIGDIR should this version
> > # number be changed to the new matplotlib version.
> > export MPLCONFIGDIR="$DOT_SAGE/matplotlib-1.5.1"
> > fi
> >
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/352EC79C-0E39-44C5-A687-1ABA8505B9EA%40gmail.com.

[kcrisman]

(I frankly don't even see why this was done in the 1st place)

> > # possible. Only when some future Matplotlib version really requires
> > # a new structure for the $MPLCONFIGDIR should this version
> > # number be changed to the new matplotlib version.
> > export MPLCONFIGDIR="$DOT_SAGE/matplotlib-1.5.1"

 

Maybe at one point MPL was changing their directory structure so quickly and often that upgrading failed for that reason?

[Matthias Koeppe]

This code is from https://trac.sagemath.org/ticket/23711