Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 401355

Summary: media-gfx/mcomix-0.96 crashes when using libunrar.so from >=app-arch/unrar-4.1.4-r1
Product: Gentoo Linux Reporter: Ryan Hill (RETIRED) <rhill>
Component: [OLD] LibraryAssignee: Ryan Hill (RETIRED) <rhill>
Status: RESOLVED FIXED    
Severity: normal    
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Ryan Hill (RETIRED) gentoo-dev 2012-01-29 17:14:15 UTC 
From bug #177402

> Can you provide a bit more detail on how mcomix crashes? Because if it's using
> dlopen() it might as well be mcomix being badly designed, rather than the
> library itself broken..

Sure.  It's a python program that wraps libunrar using ctypes.cdll.  The wrapper can be found at http://mcomix.svn.sourceforge.net/viewvc/mcomix/mcomix/archive/rarfile.py?view=markup

The segfault occurs randomly when opening cbr archives (which are just renamed rar archives).

Here's the backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe6ffd700 (LWP 22573)]
RARSetCallback (hArcData=0xe0151830, Callback=0x7ffff7fd9080, UserData=0) at dll.cpp:334
334	dll.cpp: No such file or directory.
(gdb) bt
#0  RARSetCallback (hArcData=0xe0151830, Callback=0x7ffff7fd9080, UserData=0) at dll.cpp:334
#1  0x0000003599c05d28 in ffi_call_unix64 () at ../src/x86/unix64.S:75
#2  0x0000003599c0576b in ffi_call (cif=0x7fffe6ffbb20, 
    fn=0x7fffef1c1790 <RARSetCallback(void*, UNRARCALLBACK, long)>, rvalue=<optimized out>, avalue=<optimized out>)
    at ../src/x86/ffi64.c:486
#3  0x00007ffff12bb04f in _call_function_pointer (argcount=3, resmem=0x7fffe6ffba40, restype=<optimized out>, 
    atypes=<optimized out>, avalues=0x7fffe6ffba10, 
    pProc=0x7fffef1c1790 <RARSetCallback(void*, UNRARCALLBACK, long)>, flags=4353) at Modules/_ctypes/callproc.c:827
#4  _ctypes_callproc (pProc=0x7fffef1c1790 <RARSetCallback(void*, UNRARCALLBACK, long)>, argtuple=0x0, flags=4353, 
    argtypes=<optimized out>, restype=0xbf1d20, checker=0x0) at Modules/_ctypes/callproc.c:1174
#5  0x00007ffff12b49c6 in PyCFuncPtr_call (self=<optimized out>, inargs=<optimized out>, kwds=0x0)
    at Modules/_ctypes/_ctypes.c:3911
#6  0x0000003596049793 in PyObject_Call (func=0xff3ae0, arg=<optimized out>, kw=<optimized out>)
    at Objects/abstract.c:2529
#7  0x00000035960e0bba in do_call (nk=<optimized out>, na=<optimized out>, pp_stack=0x7fffe6ffbd70, func=0xff3ae0)
    at Python/ceval.c:4231
#8  call_function (oparg=<optimized out>, pp_stack=0x7fffe6ffbd70) at Python/ceval.c:4036
#9  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666
#10 0x00000035960e24e8 in fast_function (nk=<optimized out>, na=3, n=<optimized out>, pp_stack=0x7fffe6ffbed0, 
    func=0xee1410) at Python/ceval.c:4099
#11 call_function (oparg=<optimized out>, pp_stack=0x7fffe6ffbed0) at Python/ceval.c:4034
#12 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666
#13 0x00000035960e3875 in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=<optimized out>, 
    args=<optimized out>, argcount=4, kws=0x1981eb0, kwcount=0, defs=0xedc768, defcount=1, closure=0x0)
    at Python/ceval.c:3253
---Type <return> to continue, or q <return> to quit---
#14 0x00000035960e1ade in fast_function (nk=<optimized out>, na=4, n=<optimized out>, pp_stack=0x7fffe6ffc0e0, 
    func=0xee1320) at Python/ceval.c:4109
#15 call_function (oparg=<optimized out>, pp_stack=0x7fffe6ffc0e0) at Python/ceval.c:4034
#16 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666
#17 0x00000035960e3875 in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=<optimized out>, 
    args=<optimized out>, argcount=3, kws=0x1394160, kwcount=0, defs=0xedc768, defcount=1, closure=0x0)
    at Python/ceval.c:3253
#18 0x00000035960e1ade in fast_function (nk=<optimized out>, na=3, n=<optimized out>, pp_stack=0x7fffe6ffc2f0, 
    func=0xee1320) at Python/ceval.c:4109
#19 call_function (oparg=<optimized out>, pp_stack=0x7fffe6ffc2f0) at Python/ceval.c:4034
#20 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666
#21 0x00000035960e24e8 in fast_function (nk=<optimized out>, na=2, n=<optimized out>, pp_stack=0x7fffe6ffc450, 
    func=0xf24848) at Python/ceval.c:4099
#22 call_function (oparg=<optimized out>, pp_stack=0x7fffe6ffc450) at Python/ceval.c:4034
#23 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666
#24 0x00000035960e3875 in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=<optimized out>, 
    args=<optimized out>, argcount=1, kws=0x7ffff7f91068, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:3253
#25 0x000000359606f133 in function_call (func=0xf247d0, arg=0x1912dd0, kw=0x1091420) at Objects/funcobject.c:526
#26 0x0000003596049793 in PyObject_Call (func=0xf247d0, arg=<optimized out>, kw=<optimized out>)
    at Objects/abstract.c:2529
#27 0x00000035960dec30 in ext_do_call (nk=0, na=<optimized out>, flags=<optimized out>, pp_stack=0x7fffe6ffc730, 
    func=0xf247d0) at Python/ceval.c:4326
#28 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2705
#29 0x00000035960e24e8 in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7fffe6ffc890, 
---Type <return> to continue, or q <return> to quit---
    func=0xcd95f0) at Python/ceval.c:4099
#30 call_function (oparg=<optimized out>, pp_stack=0x7fffe6ffc890) at Python/ceval.c:4034
#31 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666
#32 0x00000035960e24e8 in fast_function (nk=<optimized out>, na=1, n=<optimized out>, pp_stack=0x7fffe6ffc9f0, 
    func=0xcd9758) at Python/ceval.c:4099
#33 call_function (oparg=<optimized out>, pp_stack=0x7fffe6ffc9f0) at Python/ceval.c:4034
#34 PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2666
#35 0x00000035960e3875 in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=<optimized out>, 
    args=<optimized out>, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#36 0x000000359606f03c in function_call (func=0xcd9668, arg=0x1069390, kw=0x0) at Objects/funcobject.c:526
#37 0x0000003596049793 in PyObject_Call (func=0xcd9668, arg=<optimized out>, kw=<optimized out>)
    at Objects/abstract.c:2529
#38 0x000000359605854f in instancemethod_call (func=0xcd9668, arg=0x1069390, kw=0x0) at Objects/classobject.c:2578
#39 0x0000003596049793 in PyObject_Call (func=0x106b6e0, arg=<optimized out>, kw=<optimized out>)
    at Objects/abstract.c:2529
#40 0x00000035960dc8a7 in PyEval_CallObjectWithKeywords (func=0x106b6e0, arg=0x7ffff7f91050, kw=<optimized out>)
    at Python/ceval.c:3882
#41 0x00000035961124d2 in t_bootstrap (boot_raw=0x139f680) at ./Modules/threadmodule.c:614
#42 0x0000003595c07f1c in start_thread () from /lib64/libpthread.so.0
#43 0x00000035950e426d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115


Using libunrar.so is the preferred method of opening .cbr's, so it's a pretty well-tested code path, which is why I suspect the problem is on our end.  You can find a couple archives @ http://dev.gentoo.org/~dirtyepic/pkgs/mcomix/ if you want to play with it.  It's easiest to enable "Automatically open the next archive" in the preferences and then switch between the two with PgUp/PgDn.
Comment 1 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-01-29 17:27:59 UTC 
Can you check whether hArcData actually points to a DataSet object? It should, but it's worth checking, as the line that fails is

  Data->Cmd.Callback=Callback;

I'm not much of a Python expert, but it upsets me that when providing the parameter for RAROpenArchiveEx it uses ctypes.byref but it doesn't do that to handle when calling RARSetCallback.
Comment 2 Ryan Hill (RETIRED) gentoo-dev 2012-02-11 20:07:13 UTC 
(gdb) p hArcData 
$3 = (void *) 0xe00155a0
(gdb) x 0xe00155a0
0xe00155a0:	Cannot access memory at address 0xe00155a0

But the use of handle seems to be correct as far as I can tell.

I see a similar bug report upstream so I'll take it up there.
Comment 3 Ryan Hill (RETIRED) gentoo-dev 2012-02-12 19:02:51 UTC 
Yep, application bug.  Sorry for the noise.
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2012-02-19 02:35:32 UTC 
Fixed in 0.97.1.