Bug 807434

Summary: ipython dies of SIGSEGV when playing with python-magic library from file package
Product: [Fedora] Fedora Reporter: Eric Hopper <eric-bugs2>
Component: fileAssignee: Jan Kaluža <jkaluza>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: jkaluza
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-08 12:57:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Eric Hopper 2012-03-27 19:15:11 UTC
Description of problem:
I was fiddling around with python-magic and when I exited ipython afterward, it crashed.

Version-Release number of selected component (if applicable):
file-5.07-6.fc16.src.rpm

How reproducible:
Don't know

Steps to Reproduce:
1. Open up ipython
2. import magic
3. Play around with various magic.things as if you had no idea what any of them did.
  
Actual results:
Crash on exit

Expected results:
A clean exit

Comment 1 Jan Kaluža 2012-03-28 06:13:51 UTC
Don't you have some log from that session? It would be useful to find out what exactly you have done...

Comment 2 Eric Hopper 2012-03-28 18:05:07 UTC
Here is a sequence of commands that reliably produces a SIGSEGV:

import magic
m = magic.magic_set()
m = magic.Magic(m)
m.file('./.bash_history')
exit

I realize now after examining the package carefully that you are supposed to use the magic.open function. But that's not at all clear. If you have an API in which some methods are dangerous, hide it in a sub-package who's names starts with an '_' and make a friendly Python wrapper that doesn't have these problems as the main package people should import.

Comment 3 Jan Kaluža 2012-08-08 12:57:51 UTC
I sent the bugreport upstream, you can check it here:

http://bugs.gw.com/view.php?id=193

I think it's up to upstream to decide about future of this package, not up to maintainer.