8000 importing umath results in "*** glibc detected *** python: corrupted double-linked list" error (Trac #1462) · Issue #2059 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

importing umath results in "*** glibc detected *** python: corrupted double-linked list" error (Trac #1462) #2059

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.

Sign up for GitHub

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

Jump to bottom
Closed
thouis opened this issue Oct 19, 2012 · 6 comments
Closed

importing umath results in "*** glibc detected *** python: corrupted double-linked list" error (Trac #1462) #2059

thouis opened this issue Oct 19, 2012 · 6 comments
Labels
01 - Enhancement component: numpy._core
Milestone
1.6.0

Comments

@thouis
Copy link
Contributor
thouis commented Oct 19, 2012

Original ticket http://projects.scipy.org/numpy/ticket/1462 on 2010-04-23 by @drnlm, assigned to unknown.

As pointed out by Hodgestar on #scipy

$ PYTHONPATH=/usr/lib/python2.5/site-packages/numpy/core python
Python 2.5.5 (r255:77872, Feb  1 2010, 19:53:42) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import umath
>>> quit()
*** glibc detected *** python: corrupted double-linked list: 0x08cdc570 ***

However

$ PYTHONPATH=/usr/lib/python2.5/site-packages/numpy/core python
Python 2.5.5 (r255:77872, Feb  1 2010, 19:53:42) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import umath
>>> quit()
$

The bug is present in numpy 1.3, but is reproducible using trunk on the sparc buildbot.
@thouis thouis closed this as completed Oct 19, 2012
@numpy-gitbot
Copy link

@pv wrote on 2010-04-24

This occurs since the multiarray module (and, hence, also umath) needs some initialization before it works correctly, and apparently some cleanup code assumes the initialization really has been performed before the interpreter is exited. The initialization is done on the Python side when numpy.core is imported.

I don't think this is a bug that can occur during normal operation (you don't get it from import numpy.core.umath), so closing as a wontfix.

@numpy-gitbot
Copy link
8000

Milestone changed to Unscheduled by @pv on 2010-04-24

@numpy-gitbot
Copy link

@drnlm wrote on 2010-04-24

While it shouldn't occur in normal operation, and wontfix is probably the right choice, it is worth noting that this is triggered by pylint 0.20.0 - see http://www.logilab.org/ticket/23009 .

@numpy-gitbot
Copy link

@pv wrote on 2010-04-25

Ummh, reopening then, in case it's possible to track down if there's a way to track down where exactly the bug comes from.

@numpy-gitbot
Copy link

@pv wrote on 2010-04-25

Turns out to be the same issue as #2061

Fixed in r8364

@numpy-gitbot
Copy link

Milestone changed to 1.6.0 by @mwiebe on 2011-05-31

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
01 - Enhancement component: numpy._core
Projects
None yet
Milestone
1.6.0
Development

No branches or pull requests
2 participants
@thouis @numpy-gitbot
0