Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 971385 - pypy 2.0 JIT w/gcc-4.8 BROKEN w/ MemoryError (fix available upstream)
pypy 2.0 JIT w/gcc-4.8 BROKEN w/ MemoryError (fix available upstream)
Product: Fedora
Classification: Fedora
Component: pypy (Show other bugs)
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Matej Stuchlik
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-06-06 07:54 EDT by Thilo Fromm
Modified: 2016-01-31 21:14 EST (History)
5 users (show)

See Also:
Fixed In Version: pypy-2.0.2-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-01 01:13:54 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thilo Fromm 2013-06-06 07:54:21 EDT
Description of problem:


pypy 2.0 JIT compiler is broken, triggers MemoryError, when compiled w/ gcc 4.8. pypy 2.0 in fedora 19 has been compiled with gcc-4.8, so the JIT is messed up. It will throw a MemoryError when being run. This should affect any package requiring pypy.

I noticed this when running cura (3D printing app) on fedora 19 and tried to "prepare a print" (i.e. slice a 3D object). You do not require a 3D printer to reproduce this issue.


Version-Release number of selected component (if applicable):

Name        : pypy
Arch        : x86_64
Version     : 2.0
Release     : 0.2.b1.fc19

How reproducible:

Every time.

Steps to Reproduce:

1. start cura
2. load an object if none has been loaded automatically
3. click "Prepare" (an icon with two cogwheels).

Actual results:

cura slicing process fails with "Something went wrong during slicing!".
You can get additional information (a logfile) by clicking the "Show log" button in the lower right corner after the error happened. The logfile will show a python stack trace triggered by a MemoryError.

Expected results:

cura slices the 3D object and I get a .gcode file from the corresponding .stl file.

Additional info:

If you force cura to use /usr/bin/python instead of /usr/bin/pypy then this bug does not appear. However, not using pypy will make the slicing process about ten times slower. Since slicing *with* pypy can already take half an hour on decent hardware, not using pypy renders cura unusable.

According to https://bugs.pypy.org/issue1450, this issue has been fixed more than a month ago. A lot of other issues with pypy 2.0 have also been fixed in 2.0.2.
Comment 1 Matej Stuchlik 2013-06-10 01:53:51 EDT
Okay, I'm working on updating it to 2.0.2.
Comment 2 Miro Hrončok 2013-06-27 15:21:20 EDT
Thilo, could you please try it and karma it up?

Comment 3 Thilo Fromm 2013-06-30 10:10:09 EDT
Just ran a 'yum update' and Cura now works great, guys! Thanks for fixing!

Also, I commented on the package, but I think I need a login before I can karma-up things? So I created an account; will karma it up after the login data arrived.
Comment 4 Matej Stuchlik 2013-07-01 01:13:54 EDT
Glad to hear that Thilo, thank *you* for reporting. :)

Note You need to log in before you can comment on or make changes to this bug.