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

Segmentation fault on two instances of Magic (with custom magic_file) #30

Closed
spinus opened this issue Mar 18, 2013 · 6 comments
Closed

Comments

@spinus
Copy link

spinus commented Mar 18, 2013

When I do two instances of Magic

In [1]: import magic
In [2]: m1 = magic.Magic()
In [3]: m2 = magic.Magic()
In [4]: m1.from_file('./settings.pyc')
Out[4]: 'python 2.7 byte-compiled'
In [5]: m2.from_file('./settings.pyc')
Out[5]: 'python 2.7 byte-compiled'

but when I use Magic with custom magic file

In [1]: import magic
In [2]: m1 = magic.Magic(magic_file='my.magic')
In [3]: m2 = magic.Magic(magic_file='my.magic')
Segmentation fault

It crashes.

@ahupp
Copy link
Owner

ahupp commented Jun 3, 2013

This works fine for me. Can you try this:

$ gdb python
(gdb) set args yourscript.py
(gdb) run

Then when it crashes, type "bt" and report back. Could you also include the version of libmagic your using? What platform are you on?

@spinus
Copy link
Author

spinus commented Jun 12, 2013

I test it on debian wheey+sid,
libmagic1==5.12-2
python-magic==0.4.3 (from pypi)

on another system (also the same repo setup but upgraded recently) the problem does not exist:
libmagic1==5.14-2 (from current sid)
python-magic==0.4.3(from pypi)

cat go.py 
import magic
m1 = magic.Magic(magic_file='my.magic')
m2 = magic.Magic(magic_file='my.magic')
(gdb) set args go.py
(gdb) run
Starting program: /home/spinus/.virtualenvs/wc/bin/python go.py
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5ecc804 in ?? () from /usr/lib/x86_64-linux-gnu/libmagic.so.1
(gdb) bt
#0  0x00007ffff5ecc804 in ?? () from /usr/lib/x86_64-linux-gnu/libmagic.so.1
#1  0x00007ffff5ecd541 in ?? () from /usr/lib/x86_64-linux-gnu/libmagic.so.1
#2  0x00007ffff5ecec2e in ?? () from /usr/lib/x86_64-linux-gnu/libmagic.so.1
#3  0x00007ffff5ecf635 in ?? () from /usr/lib/x86_64-linux-gnu/libmagic.so.1
#4  0x00007ffff694b834 in ffi_call_unix64 () from /home/spinus/.virtualenvs/wc/lib/python2.7/lib-dynload/_ctypes.so
#5  0x00007ffff694b2af in ffi_call () from /home/spinus/.virtualenvs/wc/lib/python2.7/lib-dynload/_ctypes.so
#6  0x00007ffff6938fd1 in _ctypes_callproc () from /home/spinus/.virtualenvs/wc/lib/python2.7/lib-dynload/_ctypes.so
#7  0x00007ffff6939742 in ?? () from /home/spinus/.virtualenvs/wc/lib/python2.7/lib-dynload/_ctypes.so
#8  0x00000000004acc66 in PyEval_EvalFrameEx ()
#9  0x00000000004b3fd8 in PyEval_EvalCodeEx ()
#10 0x00000000004b4c77 in ?? ()
#11 0x0000000000481cc4 in ?? ()
#12 0x0000000000460d0e in PyEval_CallObjectWithKeywords ()
#13 0x0000000000486707 in PyInstance_New ()
#14 0x00000000004acc66 in PyEval_EvalFrameEx ()
#15 0x00000000004b3fd8 in PyEval_EvalCodeEx ()
#16 0x0000000000536723 in ?? ()
#17 0x0000000000446bf2 in PyRun_FileExFlags ()
#18 0x00000000004470ec in PyRun_SimpleFileExFlags ()
#19 0x0000000000447cdc in Py_Main ()
#20 0x00007ffff6f17a55 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x00000000004c7f39 in _start ()

@ahupp
Copy link
Owner

ahupp commented Jun 13, 2013

So I'm clear, you see a crash on libmagic 5.12 but not 5.14?

@spinus
Copy link
Author

spinus commented Jun 22, 2013

Yes. But I am not sure it is libmagic fault or just another component. I will try upgrade libmagic and report back here whether it helped.

@ahupp
Copy link
Owner

ahupp commented May 5, 2020

Were you able to figure this out?

@spinus
Copy link
Author

spinus commented May 7, 2020

@ahupp I'm sorry but don't remember what was the resolution. I guess I can close this as it's pretty old and probably versions of all related packages are different nowadays.

@spinus spinus closed this as completed May 7, 2020
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