Doc build issues in 8.4

[Antonio Rojas]

Hi all,
I'm running into some issues when building docs in 8.4. For some modules (combinat, categories), the build simply stops half the way (on the 'reading sources' step) without any visible error message. I've traced it to https://trac.sagemath.org/ticket/24655, specifically the part that removes the special-casing when SAGE_NUM_THREADS=1 (btw, I also had to revert the part that removes virtually all build terminal output, just to figure out what the problem was - I'm not convinced that silencing all output is a good idea). And indeed, I can reproduce the issue in 8.3 only when running the builder with SAGE_NUM_THREADS>1 (which is why I didn't run into this until now).

We are on sphinx 1.8 already, but downgrading to 1.7 makes no difference. I can't reproduce this when building the docs on sage-the-distribution, so there must be some patch *somewhere* that fixes this. I just can't figure out where it is. Does anybody have an idea?

TIA,
--Antonio

[François Bissey]

Hi Antonio,

I must say I am a bit surprised I had no problems building the doc for 8.4
in sage-on-gentoo.
Because I do some builds for almost every push on volkeR’s merge branch,
I would have noticed way before the release.
My own documentation builds are available at
http://sagetrac.lipn.univ-paris13.fr/sage/sage-8.4-doc-html.tar.xz
http://sagetrac.lipn.univ-paris13.fr/sage/sage-8.4-doc-pdf.tar.xz
I don’t know how you build the doc but I have logs.

François

> --
> You received this message because you are subscribed to the Google Groups "sage-packaging" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-packagin...@googlegroups.com.
> To post to this group, send email to sage-pa...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/a12c7912-24bb-482b-9fa4-10153630d25d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[nqn...@gmail.com]

El viernes, 19 de octubre de 2018, 21:47:08 (UTC+2), Francois Bissey escribió:
> Hi Antonio,
>
> I must say I am a bit surprised I had no problems building the doc for 8.4
> in sage-on-gentoo.
> Because I do some builds for almost every push on volkeR’s merge branch,
> I would have noticed way before the release.
> My own documentation builds are available at
> http://sagetrac.lipn.univ-paris13.fr/sage/sage-8.4-doc-html.tar.xz
> http://sagetrac.lipn.univ-paris13.fr/sage/sage-8.4-doc-pdf.tar.xz
> I don’t know how you build the doc but I have logs.

Thanks François, your reply made me look at the difference between your build script and ours, and I noticed that we are passing -k to docbuild, which makes it ignore errors (I can't remember the reason). After removing it I can see the actual problem, it is segfaulting:

Error building the documentation.
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/build/sagemath-doc/src/sage-8.4/src/sage_setup/docbuild/__main__.py", line 2, in <module>
main()
File "/build/sagemath-doc/src/sage-8.4/local-python/sage_setup/docbuild/__init__.py", line 1715, in main
builder()
File "/build/sagemath-doc/src/sage-8.4/local-python/sage_setup/docbuild/__init__.py", line 334, in _wrapper
getattr(get_builder(document), 'inventory')(*args, **kwds)
File "/build/sagemath-doc/src/sage-8.4/local-python/sage_setup/docbuild/__init__.py", line 529, in _wrapper
build_many(build_ref_doc, L)
File "/build/sagemath-doc/src/sage-8.4/local-python/sage_setup/docbuild/__init__.py", line 283, in build_many
ret = x.get(99999)
File "/usr/lib/python2.7/multiprocessing/pool.py", line 572, in get
raise self._value
Exception: ('Non-exception during docbuild: Segmentation fault', SignalError('Segmentation fault',))

[Jeroen Demeyer]

On 2018-10-19 20:56, Antonio Rojas wrote:
> I've traced it to https://trac.sagemath.org/ticket/24655, specifically the part that removes the special-casing when SAGE_NUM_THREADS=1 (btw, I also had to revert the part that removes virtually all build terminal output, just to figure out what the problem was - I'm not convinced that silencing all output is a good idea).

I agree here. Why were all those changes to the docbuilder made on
#24655? I haven't followed that ticket (thinking that it was just about
CI) but those changes should be motivated better or reverted.

[Dima Pasechnik]

if you read this whole thread you see that a part of the problem was Antonio's calling docbuild with -k and thus missing a segfault...

on the ticket there is a workaround for a claimed memory leak by Sphinx, too...

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

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/5BCAF0D6.80109%40UGent.be.

[Jeroen Demeyer]

On 2018-10-20 11:35, Dima Pasechnik wrote:
> on the ticket there is a workaround for a claimed memory leak by Sphinx,
> too...

If the people on that ticket thought that there is a problem with
Sphinx, they should have opened a new ticket for that instead of making
changes to the docbuilder in a completely unrelated ticket.

[Timo Kaufmann]

I think I'm seeing the same error. bisecting shows it was introduced in 8.4.beta2, which is the release where the CI ticket was merged. I don't test the docbuild often enough because it takes so long and eats ridiculous amount of RAM, which is why I didn't notice until now.

Curiously I run it with `SAGE_NUM_THREADS` > 1 and never experienced the problem before. To be precise I first set `SAGE_NUM_THREAD` to the number of threads the build is configured to use (4 in case of my local machine) and then run

sage -python -m sage_setup.docbuild --mathjax --no-pdf-links all html

[Julian Rüth]

I guess I am to blame for whatever broke the docbuild since I am the
author of that CI ticket.

Unfortunately, I have no idea where the problems you are seeing come
from. It's been 6 months since I made these changes, so I do not recall
all the details. Here is some context that may or may not be useful
while debugging this:

I removed the code path for NUM_THREADS=1 that used to call sphinx
without forking. IIRC embray had added this for Windows but he thought
that it was not needed anymore. IIRC calling sphinx serially
made me run out of RAM on the CI machines that only had small amounts of
RAM as sphinx is leaking memory for us (which is not Sphinx's fault, you
are not supposed to call sphinx in the way that we are/were calling it.)

Probably unrelated, but setting NUM_THREADS too high would also lead to
problems as Linux would think that I am asking for too much RAM with the
fork() calls as Sage is already quite heavy when the fork happens.
Changing the overcommit policy of the Linux system solved that locally
but wasn't something I could do on the CI machines. IIRC I've seen
segfaults coming out of tachyon in this case (spawning tachyon forks the
main processs which then exceeds the overcommit limit.)

I don't think that I changed anything else of relevance in that ticket
regarding the docbuild except for some mangling of sphinx output
(otherwise we would run into stdout limits on the CI systems.)

Sorry for causing these problems,

julian

* Timo Kaufmann <eisf...@gmail.com> [2018-10-20 09:28:17 -0700]:

> I think I'm seeing the same error. bisecting shows it was introduced in 8.4.beta2, which is the release where the CI ticket was merged. I don't test the docbuild often enough because it takes so long and eats ridiculous amount of RAM, which is why I didn't notice until now.
>
> Curiously I run it with `SAGE_NUM_THREADS` > 1 and never experienced the problem before. To be precise I first set `SAGE_NUM_THREAD` to the number of threads the build is configured to use (4 in case of my local machine) and then run
>
> sage -python -m sage_setup.docbuild --mathjax --no-pdf-links all html
>

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/b3ecfffe-2abd-4983-8286-97e205c424c6%40googlegroups.com.

[Antonio Rojas]

Hi Julian,

El sábado, 20 de octubre de 2018, 19:10:43 (UTC+2), Julian Rüth escribió:
> I guess I am to blame for whatever broke the docbuild since I am the
> author of that CI ticket.

Not really, as mentioned in my original post your patch simply unmasked the issue by removing the special codepath for SAGE_NUM_THREADS=1. The actual cause of the segfault is still unknown. I take it you can't reproduce it in Debian either?

My only issue with the patch is that it removes too much build output. Some modules take a few minutes to compile, and it is now easy to think that the build is stuck, since no progress information is displayed at all.

[Timo Kaufmann]

Reverting 7d85dc796c58c3de57401bc22d3587b94e205091 ("Something related to the sphinxbuild seems to be leaking memory", the commit removing the special-casing) makes the docbuild work for me. I thought I already exercised the "> 1 threads" code path before, but apparently I didn't. When I patch the `if NUM_THREADS > 1` to a `if True`, I get the failure again. That is even though `SAGE_NUM_THREADS` is explicitly set and exported to something >1, which seems to be ignored for some reason.

[Antonio Rojas]

El viernes, 19 de octubre de 2018, 22:16:52 (UTC+2), nqn...@gmail.com escribió:
> Thanks François, your reply made me look at the difference between your build script and ours, and I noticed that we are passing -k to docbuild, which makes it ignore errors (I can't remember the reason). After removing it I can see the actual problem, it is segfaulting:
>

> ...

> /multiprocessing/pool.py", line 572, in get
> raise self._value
> Exception: ('Non-exception during docbuild: Segmentation fault', SignalError('Segmentation fault',))

I found the cause of the segfault: it's due to threaded pari. After recompiling pari without threads the docs build correctly. Unfortunately I have an extremely limited knowledge about threading code, so any hint about how to go about fixing this would be appreciated.

[Erik Bray]

It wasn't completely unrelated. It was motivated by getting the docs
to build in the CI pipeline. I'm not sure why you think those changes
are a problem.

[Erik Bray]

That seems more likely to be related. Our current use of the
multiprocessing module for parallel doc builds is such that crashes
like segfaults are not well handled; the main process will wait
forever for a result from the crashed process that never arrives,
IIUC. I have seen problems on 8.4 with docbuilds hanging as well, and
I don't think it started with #24655. If I can reproduce the problem
again I'll be able to investigate more.

For some reason it happens on some of my machines but not others.

[Dima Pasechnik]

There are open Sage tickets about Sage's crashes due to multithreading.

(In particular related to the use of threads in ipython tab completion.)

So this might be something of this sort: Pari expects certain tasks/calls only to happen in "main" thread, and this is violated by sphinx.

--
You received this message because you are subscribed to the Google Groups "sage-packaging" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-packaging+unsubscribe@googlegroups.com.
To post to this group, send email to sage-packaging@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/faecedca-68f2-48b6-bfb7-f8867c816a8d%40googlegroups.com.

[Ximin Luo]

I have a patch to make sage's docbuild run sphinx in separate processes instead of threads, this might provide some protection against these sorts of things. Ofc this is only for the docbuild, so "real sage code" might still be affected by whatever underlying pari issue is causing this.

https://salsa.debian.org/science-team/sagemath/blob/master/debian/patches/df-subprocess-sphinx.patch

X

Dima Pasechnik:

> There are open Sage tickets about Sage's crashes due to multithreading.
> (In particular related to the use of threads in ipython tab completion.)
>
> So this might be something of this sort: Pari expects certain tasks/calls
> only to happen in "main" thread, and this is violated by sphinx.
>
>
>
> On 28 Oct 2018 9:39 am, "Antonio Rojas" <nqn...@gmail.com> wrote:
>
>> El viernes, 19 de octubre de 2018, 22:16:52 (UTC+2), nqn...@gmail.com
>> escribió:
>>> Thanks François, your reply made me look at the difference between your
>> build script and ours, and I noticed that we are passing -k to docbuild,
>> which makes it ignore errors (I can't remember the reason). After removing
>> it I can see the actual problem, it is segfaulting:
>>>
>>> ...
>>> /multiprocessing/pool.py", line 572, in get
>>> raise self._value
>>> Exception: ('Non-exception during docbuild: Segmentation fault',
>> SignalError('Segmentation fault',))
>>
>> I found the cause of the segfault: it's due to threaded pari. After
>> recompiling pari without threads the docs build correctly. Unfortunately I
>> have an extremely limited knowledge about threading code, so any hint about
>> how to go about fixing this would be appreciated.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-packaging" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to sage-packagin...@googlegroups.com.
>> To post to this group, send email to sage-pa...@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/sage-packaging/faecedca-68f2-48b6-bfb7-f8867c816a8d%
>> 40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

[Timo Kaufmann]

Am Sonntag, 28. Oktober 2018 21:09:18 UTC+1 schrieb Dima Pasechnik:
> There are open Sage tickets about Sage's crashes due to multithreading.
> (In particular related to the use of threads in ipython tab completion.)
>
>
> So this might be something of this sort: Pari expects certain tasks/calls only to happen in "main" thread, and this is violated by sphinx.
>
>
>
>
>
>
> On 28 Oct 2018 9:39 am, "Antonio Rojas" <nqn...@gmail.com> wrote:
> El viernes, 19 de octubre de 2018, 22:16:52 (UTC+2), nqn...@gmail.com  escribió:
>
> > Thanks François, your reply made me look at the difference between your build script and ours, and I noticed that we are passing -k to docbuild, which makes it ignore errors (I can't remember the reason). After removing it I can see the actual problem, it is segfaulting:
>
> >
>
> > ...
>
> > /multiprocessing/pool.py", line 572, in get
>
> >     raise self._value
>
> > Exception: ('Non-exception during docbuild: Segmentation fault', SignalError('Segmentation fault',))
>
>
>
> I found the cause of the segfault: it's due to threaded pari. After recompiling pari without threads the docs build correctly. Unfortunately I have an extremely limited knowledge about threading code, so any hint about how to go about fixing this would be appreciated.
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "sage-packaging" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-packagin...@googlegroups.com.
>
> To post to this group, send email to sage-pa...@googlegroups.com.

>
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/faecedca-68f2-48b6-bfb7-f8867c816a8d%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

Are there any other known issues with threaded pari in particular? Should I modify the pari I use for sage? I haven't encountered any issues except the docbuild yet. If the docbuild is the only issue, we should probably open a ticket for that and if we can fix it maybe even enable threads in sage-the-dist pari.

[Antonio Rojas]

El martes, 30 de octubre de 2018, 11:11:39 (UTC+1), Timo Kaufmann escribió:

> Are there any other known issues with threaded pari in particular? Should I modify the pari I use for sage? I haven't encountered any issues except the docbuild yet. If the docbuild is the only issue, we should probably open a ticket for that and if we can fix it maybe even enable threads in sage-the-dist pari.

Well, you did push a fix to disable threads usage in libpari, which is included in 8.4. So the question is why it seems not to have an effect on docbuild.

[Timo Kaufmann]

Oh right, forgot about that. What does the docbuild use pari for anyways?

[Antonio Rojas]

El martes, 30 de octubre de 2018, 12:21:00 (UTC+1), Timo Kaufmann escribió:
>
> Oh right, forgot about that. What does the docbuild use pari for anyways?

It is called indirectly via matplotlib when rendering plots, see full backtrace below (btw, I had to downgrade to an old version of Sage to get a meaningful backtrace - I really dislike this trend of hiding build output, it makes it very hard to debug stuff)

The backtrace shows that the segfault happens on cysignals (sig_on), which may explain why your patch doesn't have any effect.

Traceback (most recent call last):

File "/usr/lib/python2.7/multiprocessing/process.py", line 267, in _bootstrap
self.run()
File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/python2.7/multiprocessing/pool.py", line 113, in worker
result = (True, func(*args, **kwds))
File "/usr/lib/python2.7/multiprocessing/pool.py", line 65, in mapstar
return map(*args)
File "/build/sagemath-doc/src/sage-8.0/local-python/sage_setup/docbuild/__init__.py", line 70, in build_ref_doc
getattr(ReferenceSubBuilder(doc, lang), format)(*args, **kwds)
File "/build/sagemath-doc/src/sage-8.0/local-python/sage_setup/docbuild/__init__.py", line 720, in _wrapper
getattr(DocBuilder, build_type)(self, *args, **kwds)
File "/build/sagemath-doc/src/sage-8.0/local-python/sage_setup/docbuild/__init__.py", line 104, in f
runsphinx()
File "/build/sagemath-doc/src/sage-8.0/local-python/sage_setup/docbuild/sphinxbuild.py", line 207, in runsphinx
sphinx.cmdline.main(sys.argv)
File "/usr/lib/python2.7/site-packages/sphinx/cmdline.py", line 296, in main
app.build(opts.force_all, filenames)
File "/usr/lib/python2.7/site-packages/sphinx/application.py", line 333, in build
self.builder.build_update()
File "/usr/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 251, in build_update
'out of date' % len(to_build))
File "/usr/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 265, in build
self.doctreedir, self.app))
File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", line 549, in update
self._read_serial(docnames, app)
File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", line 569, in _read_serial
self.read_doc(docname, app)
File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", line 677, in read_doc
pub.publish()
File "/usr/lib/python2.7/site-packages/docutils/core.py", line 217, in publish
self.settings)
File "/usr/lib/python2.7/site-packages/sphinx/io.py", line 55, in read
self.parse()
File "/usr/lib/python2.7/site-packages/docutils/readers/__init__.py", line 78, in parse
self.parser.parse(self.input, document)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/__init__.py", line 191, in parse
self.statemachine.run(inputlines, document, inliner=self.inliner)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 171, in run
input_source=document['source'])
File "/usr/lib/python2.7/site-packages/docutils/statemachine.py", line 239, in run
context, state, transitions)
File "/usr/lib/python2.7/site-packages/docutils/statemachine.py", line 460, in check_line
return method(match, context, next_state)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2753, in underline
self.section(title, source, style, lineno - 1, messages)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 327, in section
self.new_subsection(title, lineno, messages)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 395, in new_subsection
node=section_node, match_titles=True)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 282, in nested_parse
node=node, match_titles=match_titles)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 196, in run
results = StateMachineWS.run(self, input_lines, input_offset)
File "/usr/lib/python2.7/site-packages/docutils/statemachine.py", line 239, in run
context, state, transitions)
File "/usr/lib/python2.7/site-packages/docutils/statemachine.py", line 460, in check_line
return method(match, context, next_state)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2328, in explicit_markup
self.explicit_list(blank_finish)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2358, in explicit_list
match_titles=self.state_machine.match_titles)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 319, in nested_list_parse
node=node, match_titles=match_titles)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 196, in run
results = StateMachineWS.run(self, input_lines, input_offset)
File "/usr/lib/python2.7/site-packages/docutils/statemachine.py", line 239, in run
context, state, transitions)
File "/usr/lib/python2.7/site-packages/docutils/statemachine.py", line 460, in check_line
return method(match, context, next_state)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2631, in explicit_markup
nodelist, blank_finish = self.explicit_construct(match)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2338, in explicit_construct
return method(self, expmatch)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2081, in directive
directive_class, match, type_name, option_presets)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2130, in run_directive
result = directive_instance.run()
File "/build/sagemath-doc/src/sage-8.0/src/sage_setup/docbuild/ext/sage_autodoc.py", line 1749, in run
nested_parse_with_titles(self.state, self.result, node)
File "/usr/lib/python2.7/site-packages/sphinx/util/nodes.py", line 208, in nested_parse_with_titles
return state.nested_parse(content, 0, node, match_titles=1)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 282, in nested_parse
node=node, match_titles=match_titles)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 196, in run
results = StateMachineWS.run(self, input_lines, input_offset)
File "/usr/lib/python2.7/site-packages/docutils/statemachine.py", line 239, in run
context, state, transitions)
File "/usr/lib/python2.7/site-packages/docutils/statemachine.py", line 460, in check_line
return method(match, context, next_state)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2326, in explicit_markup
nodelist, blank_finish = self.explicit_construct(match)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2338, in explicit_construct
return method(self, expmatch)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2081, in directive
directive_class, match, type_name, option_presets)
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/states.py", line 2130, in run_directive
result = directive_instance.run()
File "/usr/lib/python2.7/site-packages/docutils/parsers/rst/__init__.py", line 410, in run
self.state, self.state_machine)
File "/usr/lib/python2.7/site-packages/matplotlib/sphinxext/plot_directive.py", line 189, in plot_directive
return run(arguments, content, options, state_machine, state, lineno)
File "/usr/lib/python2.7/site-packages/matplotlib/sphinxext/plot_directive.py", line 779, in run
close_figs=context_opt == 'close-figs')
File "/usr/lib/python2.7/site-packages/matplotlib/sphinxext/plot_directive.py", line 644, in render_figures
run_code(code_piece, code_path, ns, function_name)
File "/usr/lib/python2.7/site-packages/matplotlib/sphinxext/plot_directive.py", line 524, in run_code
six.exec_(code, ns)
File "/usr/lib/python2.7/site-packages/six.py", line 709, in exec_
exec("""exec _code_ in _globs_, _locs_""")
File "<string>", line 1, in <module>
File "<string>", line 1, in <module>
File "sage/misc/classcall_metaclass.pyx", line 329, in sage.misc.classcall_metaclass.ClasscallMetaclass.__call__ (build/cythonized/sage/misc/classcall_metaclass.c:1698)
if cls.classcall is not None:
File "/usr/lib/python2.7/site-packages/sage/geometry/triangulation/point_configuration.py", line 331, in __classcall__
.__classcall__(cls, points, connected, fine, regular, star, defined_affine)
File "sage/misc/cachefunc.pyx", line 1005, in sage.misc.cachefunc.CachedFunction.__call__ (build/cythonized/sage/misc/cachefunc.c:6065)
ArgSpec(args=['self', 'algorithm', 'deg_bound', 'mult_bound', 'prot'],
File "/usr/lib/python2.7/site-packages/sage/structure/unique_representation.py", line 1027, in __classcall__
instance = typecall(cls, *args, **options)
File "sage/misc/classcall_metaclass.pyx", line 496, in sage.misc.classcall_metaclass.typecall (build/cythonized/sage/misc/classcall_metaclass.c:2148)
"""
File "/usr/lib/python2.7/site-packages/sage/geometry/triangulation/point_configuration.py", line 367, in __init__
PointConfiguration_base.__init__(self, points, defined_affine)
File "sage/geometry/triangulation/base.pyx", line 398, in sage.geometry.triangulation.base.PointConfiguration_base.__init__ (build/cythonized/sage/geometry/triangulation/base.cpp:4135)
self._init_points(points)
File "sage/geometry/triangulation/base.pyx", line 456, in sage.geometry.triangulation.base.PointConfiguration_base._init_points (build/cythonized/sage/geometry/triangulation/base.cpp:4982)
red = matrix([ red.row(i) for i in red.pivot_rows()])
File "sage/matrix/matrix2.pyx", line 517, in sage.matrix.matrix2.Matrix.pivot_rows (build/cythonized/sage/matrix/matrix2.c:8414)
"""
File "sage/matrix/matrix_integer_dense.pyx", line 2217, in sage.matrix.matrix_integer_dense.Matrix_integer_dense.pivots (build/cythonized/sage/matrix/matrix_integer_dense.c:19162)
sage: matrix(3, range(9)).elementary_divisors()
File "sage/matrix/matrix_integer_dense.pyx", line 2019, in sage.matrix.matrix_integer_dense.Matrix_integer_dense.echelon_form (build/cythonized/sage/matrix/matrix_integer_dense.c:17749)

File "sage/matrix/matrix_integer_dense.pyx", line 5719, in sage.matrix.matrix_integer_dense.Matrix_integer_dense._hnf_pari (build/cythonized/sage/matrix/matrix_integer_dense.c:46635)
most `\max\mathcal{S}` where `\mathcal{S}` denotes the full
SignalError: Segmentation fault

[Timo Kaufmann]

It looks like the file mentioned in the backtrace `src/sage/matrix/matrix_integer_dense.pyx` works with pari's C interface directly. I'm not sure how the cython stuff and `cimport` work, but that is probably the reason.

[Timo Kaufmann]

Also I just noticed that there is a whole other expect based pari interface in `src/sage/interfaces/gp.py`. That would probably also need a patch like in https://trac.sagemath.org/ticket/26002 (patching that interface doesn't fix the docbuild though).

[François Bissey]

I don’t expect so. In #26002 we are talking about using threads from libpari. Which means
I believe you would have sage forking itself and that’s where things get complicated.
Stuff in interface is managed by pexpect and that means a separate, independent, executable
is started and you are waiting for the results from that executable. Wether that executable
uses thread or not has no real effect on sage.

François

> On 31/10/2018, at 12:22, Timo Kaufmann <eisf...@gmail.com> wrote:
>
> Also I just noticed that there is a whole other expect based pari interface in `src/sage/interfaces/gp.py`. That would probably also need a patch like in https://trac.sagemath.org/ticket/26002 (patching that interface doesn't fix the docbuild though).
>

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-packaging/6cd96ac6-a721-45e3-8ef2-37ccdf9304e9%40googlegroups.com.

[Timo Kaufmann]

Right that makes sense, didn't think that through. The direct c-bindings in matrix_integer_dense.pyx are probably the issue.

[Timo Kaufmann]

I've created a trac ticket, let's continue there: https://trac.sagemath.org/ticket/26608