Sage Crash Report

51 views
Skip to first unread message

vesel...@gmail.com

unread,
Jun 17, 2017, 6:42:42 AM6/17/17
to sage-support
Hi,

i install SageMath from binaries
sage-7.6-Ubuntu_16.04-x86_64.tar.bz2

I expand package and run
./sage

Then the installation crash.

My system is Xubuntu 16.04

Thank you for help
Sage_crash_report.txt

vesel...@gmail.com

unread,
Jun 17, 2017, 6:49:33 AM6/17/17
to sage-support
Sorry, it is cause missing gfortran.
Now it is working fine.

Dne sobota 17. června 2017 12:42:42 UTC+2 vesel...@gmail.com napsal(a):

Srinivas K

unread,
Jun 18, 2017, 6:56:16 AM6/18/17
to sage-s...@googlegroups.com

Sage Crashed when opening from a terminal at a directory. Sage configuration is a fresh copy compiled from source (version 7.6) with no configuration. I have only run tests using sage --testall. Sage only crashes in this particular directory which has my python modules and also happens to be a git repo. I have tried in other git repos and directories but it works fine.

I have attached the crash report.
Sage_crash_report.txt

Dima Pasechnik

unread,
Jun 18, 2017, 7:41:22 AM6/18/17
to sage-support
git repo is not relevant, but a python module that shadows a Sage python module would be a problem.

John H Palmieri

unread,
Jun 18, 2017, 12:02:50 PM6/18/17
to sage-support


On Sunday, June 18, 2017 at 4:41:22 AM UTC-7, Dima Pasechnik wrote:
git repo is not relevant, but a python module that shadows a Sage python module would be a problem.

For example, if you have your own file "parser.py", it would interfere with the standard Python module "parser".

whit3rd

unread,
Jun 21, 2017, 4:04:12 AM6/21/17
to sage-support
Seconds after install of version 7.6, on MacOS 10.11.6
on a MacBook Pro (Core 2 duo, 4GB RAM)

On initially installing Sage, there was one warning
***
/Applications/SageMath/src/bin/sage-env: line 291: /sw/bin/sed: Bad CPU type in executable
**
then this crash happened seconds after it seemed to complete, after
 the prompt
***
│ SageMath version 7.6, Release Date: 2017-03-25                     │
│ Type "notebook()" for the browser-based notebook interface.        │
│ Type "help()" for help.                                            │
***

Sage_crash_report.txt

Dima Pasechnik

unread,
Jun 21, 2017, 6:01:09 AM6/21/17
to sage-support


On Wednesday, June 21, 2017 at 9:04:12 AM UTC+1, whit3rd wrote:
Seconds after install of version 7.6, on MacOS 10.11.6
on a MacBook Pro (Core 2 duo, 4GB RAM)

it might be that the executable you downloaded needs a better CPU (Core 2 duo is quite old...)
What exactly have you installed, what file?

As well, it might be that you have some kind of conflict with some stuff in /sw/ you have in your PATH.
Could you temporarily rename /sw/ and try again?

whit3rd

unread,
Jun 22, 2017, 2:35:00 AM6/22/17
to sage-support


On Wednesday, June 21, 2017 at 3:01:09 AM UTC-7, Dima Pasechnik wrote:


On Wednesday, June 21, 2017 at 9:04:12 AM UTC+1, whit3rd wrote:
Seconds after install of version 7.6, on MacOS 10.11.6
on a MacBook Pro (Core 2 duo, 4GB RAM)

it might be that the executable you downloaded needs a better CPU (Core 2 duo is quite old...)
What exactly have you installed, what file?

It's "sage-7.6-OSX_10.11.6-x86_64.dmg" for the installer.

Core 2 is certainly  both x86 and 64-bit.   This CPU is 2.26 GHz, probably Penryn P8400 or SP9300
Apple MacBook Pro 5.5 is the machine designation
 
As well, it might be that you have some kind of conflict with some stuff in /sw/ you have in your PATH.
Could you temporarily rename /sw/ and try again?

That works!  Don't see any reason there'd be conflict, though.  Sage doesn't put anything into /sw,
 but /sw overrides anyhow?

How might I restore the /sw directory and still keep Sage running?

Dima Pasechnik

unread,
Jun 22, 2017, 4:21:06 AM6/22/17
to sage-support
It should be enough to run Sage in a shell session where PATH variable does not contain anything from /sw/.

(there may be more variable that might affect running Sage, although this is probably a bug then)

PS. it is true that Core2 duo is x86_64, but not all such CPUs are created equal. Different CPUs support different machine hardware commands, and compilers are able to use this to produce faster code, at expense of portability. This is why a binary distribution needs to use the most basic subset of machine commands to be useful on all x86_64s.


Reply all
Reply to author
Forward
0 new messages