Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sage fails to start on Fedora 32 after the recent update to Python 3.8 #30868

Closed
AndrewLyasoff mannequin opened this issue Nov 7, 2020 · 6 comments
Closed

sage fails to start on Fedora 32 after the recent update to Python 3.8 #30868

AndrewLyasoff mannequin opened this issue Nov 7, 2020 · 6 comments

Comments

@AndrewLyasoff
Copy link
Mannequin

AndrewLyasoff mannequin commented Nov 7, 2020

The crash report is attached. The installation is from the latest Fedora 32 package (sage 9.0).

Component: build

Reviewer: Samuel Lelièvre

Issue created by migration from https://trac.sagemath.org/ticket/30868

@AndrewLyasoff AndrewLyasoff mannequin added this to the sage-9.3 milestone Nov 7, 2020
@AndrewLyasoff

This comment has been minimized.

@AndrewLyasoff
Copy link
Mannequin Author

AndrewLyasoff mannequin commented Nov 7, 2020

comment:1

Attachment: Sage_crash_report.txt

@mkoeppe
Copy link
Member

mkoeppe commented Nov 7, 2020

comment:2

Report Fedora packaging bugs to Fedora.

@mkoeppe mkoeppe removed this from the sage-9.3 milestone Nov 7, 2020
@jamesjer
Copy link
Mannequin

jamesjer mannequin commented Nov 9, 2020

comment:3

For the record, this started happening when giac was updated from version 1.6.0-7 to version 1.6.0-25. The way giac initializes pari was changed. Sagemath starts up and initializes cypari2, which stores the value of avma. Later, giac is loaded. It initializes pari a second time, creating an entirely new stack and a new value of avma. When cypari2 is next used, it tries to use values on the old stack, but they are not valid stack slots because giac made a new pari stack.

I am going to try enabling TLS support in pari to see if that is sufficient. That way, cypari2 and giac threads can use different pari stacks, at the cost of consuming more memory.

@mkoeppe
Copy link
Member

mkoeppe commented Nov 9, 2020

comment:4

This is probably best discussed in #30537, our giac 1.6 upgrade ticket

@slel
Copy link
Member

slel commented Jan 2, 2021

Reviewer: Samuel Lelièvre

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants