Comix has not been updated for about 2 years now. For some time however, there is a fork called MComix:
"MComix is a fork of the Comix project, and aims to add bug fixes and stability improvements after Comix development came to a halt in late 2009."
Fedora should ship this instead of Comix in upcoming versions.
While I have not decided whether to make comix obsoleted or not, now I am trying to package mcomix. Thank you for information.
Well, packaging is almost done, however compared to comix, mcomix
- cannot handle some archives which comix can handle with no problem
- sometimes (frequently) hangs up, and I have to resort to kill -9 mcomix
So currently I cannot find any advantage on mcomix over comix, so
until I can find out what is happening on mcomix, I will postpone importing
mcomix into Fedora.
I am currently in charge of maintaining and updating MComix, and as such, am interested in the problems you are describing.
> - cannot handle some archives which comix can handle with no problem
Could you elaborate on this? In my experience, MComix should at least handle the same kind of archives as Comix, seeing that the archive extraction code for major archive formats was only slightly modified. Example archives would be appreciated.
> - sometimes (frequently) hangs up, and I have to resort to kill -9 mcomix
Are there definite symptoms accompanying the hang, such as exception backtraces on the console or certain reproducible steps that can be taken? I was under the (perhaps misguided) impression that MComix should be fairly stable at this point in time.
In any case, the the bug tracker for MComix is at http://sf.net/projects/mcomix/. Please post any specific bugs there, so I can look into them in more detail.
(In reply to comment #3)
> I am currently in charge of maintaining and updating MComix, and as such, am
> interested in the problems you are describing.
> > - cannot handle some archives which comix can handle with no problem
> Could you elaborate on this? In my experience, MComix should at least handle
> the same kind of archives as Comix, seeing that the archive extraction code for
> major archive formats was only slightly modified. Example archives would be
> > - sometimes (frequently) hangs up, and I have to resort to kill -9 mcomix
> Are there definite symptoms accompanying the hang, such as exception backtraces
> on the console or certain reproducible steps that can be taken? I was under the
> (perhaps misguided) impression that MComix should be fairly stable at this
> point in time.
Unpacking rar archives fail by about 80% or so. mcomix may show only first a few pages or nothing, and in such cases mcomix usually hangs up (I have unrar installed). I guess there is some mishandling about pipe process.
> In any case, the the bug tracker for MComix is at
> http://sf.net/projects/mcomix/. Please post any specific bugs there, so I can
> look into them in more detail.
Created attachment 520440 [details]
Attempt to fix pipe-related deadlocks
Thank you for responding. However, I was unable to reproduce the issue on my own Gentoo box, a Fedora live CD I pulled, and on my Windows box. I could imagine that MComix might hang up when unrar doesn't terminate correctly (due to MComix waiting for the process to end), but I haven't actually encountered this problem in practice since I started working on MComix.
Another reason might be that Python apparently deadlocks in some cases when calling wait() on a process that is still waiting to send data to the OS pipe buffer. Again, I haven't seen this myself, but it might be related to the speed the pipe is filled, so maybe having a slower system helps avoiding the issue.
Could you please test if the attached patch fixes the problem?
I tried your patch in comment 5 but the problems I see still persist (I don't know if this is related, however I am using F-16)
Using a Fedora 16 live CD, I finally managed to reproduce the issue. It appears that in some cases, subprocess.Popen never returns. I traced the execution into /usr/lib/python2.7/subprocess.py, and it appears that the child portion of os.fork() occasionally hangs up. I do not know what exactly constitutes this behavior, as a simple test case I wrote did not trigger the same problem. Furthermore, the process spawning code of MComix is virtually identical to Comix.
Going back a few MComix versions, it appears that the problem existed back in the first version of MComix, but to be honest, I don't even see any changes that could have prompted such a divergence in behavior.
Since this problem seems to be absent on any other Linux distribution I tried, I cannot rule out that a bug in a system package might be responsible.
Are there any good news on hangup issue?
Created attachment 526230 [details]
Disables threading for unpacking with external applications
Well, I don't know if this is any good or not, but I've been experimenting with disabling threading while extracting files. Maybe some Python global interpreter lock is still being held somewhere when fork() is called.
While I haven't experienced any freezes recently, it would still be nice if someone could test the changes. I am attaching the most recent patch.
It seems that I no longer see hangup issue even without the patch attached on comment 9 with mcomix 0.94 (not sure if mcomix side or something else got fixed).
Review request submitted as bug 744628 . If someone can review it I will appreciate it, thanks.
mcomix is now imported into F-17/16/15. For F-16/15, the new packages will appear on testing repository in a few days. I will appreciate it if you would test them.
Note that currently I made comix and mconix parallel installable, so installing mcomix won't obsolete comix. I may consider to make mcomix obsolete comix on f-17+, however it won't occur on F-16/15.
Thanks for your work guys, works great for me.