Bug 730490 - Comix to MComix
Summary: Comix to MComix
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mcomix
Version: 16
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 744628
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-13 16:42 UTC by Michael Monreal
Modified: 2011-10-29 08:13 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-28 04:35:31 UTC


Attachments (Terms of Use)
Attempt to fix pipe-related deadlocks (1.44 KB, patch)
2011-08-29 17:19 UTC, oddegamra
no flags Details | Diff
Disables threading for unpacking with external applications (2.19 KB, patch)
2011-10-04 11:10 UTC, oddegamra
no flags Details | Diff

Description Michael Monreal 2011-08-13 16:42:59 UTC
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.

[1] http://mcomix.sourceforge.net/

Comment 1 Mamoru TASAKA 2011-08-21 14:18:18 UTC
While I have not decided whether to make comix obsoleted or not, now I am trying to package mcomix. Thank you for information.

Comment 2 Mamoru TASAKA 2011-08-28 14:18:59 UTC
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.

Comment 3 oddegamra 2011-08-28 17:17:43 UTC
Hello,

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.

Comment 4 Mamoru TASAKA 2011-08-29 16:06:21 UTC
(In reply to comment #3)
> Hello,
> 
> 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.

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.

Comment 5 oddegamra 2011-08-29 17:19:27 UTC
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?

Comment 6 Mamoru TASAKA 2011-08-29 23:11:04 UTC
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)

Comment 7 oddegamra 2011-08-30 08:22:26 UTC
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.

Comment 8 Mamoru TASAKA 2011-10-01 20:20:50 UTC
Are there any good news on hangup issue?

Comment 9 oddegamra 2011-10-04 11:10:12 UTC
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.

Comment 10 Mamoru TASAKA 2011-10-09 19:36:55 UTC
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.

Comment 11 Mamoru TASAKA 2011-10-28 04:35:31 UTC
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.

Comment 12 Mamoru TASAKA 2011-10-28 04:37:53 UTC
c.f.
https://admin.fedoraproject.org/pkgdb/acls/name/mcomix

Comment 13 Michael Monreal 2011-10-29 08:13:36 UTC
Thanks for your work guys, works great for me.


Note You need to log in before you can comment on or make changes to this bug.