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.
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.
(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.
Yep, application bug. Sorry for the noise.
Fixed in 0.97.1.