| Summary: | xv hangs on SIGQUIT unless manual interaction first | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Trevor Cordes <rpmfusion> |
| Component: | xv | Assignee: | L. Gabriel Somlo <somlo> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | leigh123linux, rickrich, sergio |
| Priority: | P5 | ||
| Version: | 26 | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| namespace: | |||
RPMFusion is no longer releasing updates for this version of Fedora. This bug will be set to RESOLVED:EXPIRED next week to reflect this. If the problem persists after upgrading to the latest version of Fedora, please update the version field of this bug (and re-open it if it has been closed). Upgraded to F21 recently, and switched from i386 to x86_64. This bug still remains (just tested it). Here's some easier steps to follow to reproduce this bug: (in tcsh, bash may vary) xv pic.jpg & kill -QUIT %1 # cpu now goes to 100% and xv is hung, confirm by right-clicking in xv, etc kill %1 RPMFusion is no longer releasing updates for this version of Fedora. This bug will be set to RESOLVED:EXPIRED next week to reflect this. If the problem persists after upgrading to the latest version of Fedora, please update the version field of this bug (and re-open it if it has been closed). Bug remains in F22, just tested. it works for me in F23 with xv-3.10a.jumbopatch.20070520-23.fc23, but this version is not build in F22 Kwizart please build xv - nonfree for F22 , because we miss this build . Thanks. (In reply to comment #5) > it works for me in F23 with xv-3.10a.jumbopatch.20070520-23.fc23, but this > version is not build in F22 > > Kwizart please build xv - nonfree for F22 , because we miss this build . > Thanks. It should be in f22-nonfree-updates from 07/2015 ? Do we need to rebuild it ? (In reply to comment #6) > It should be in f22-nonfree-updates from 07/2015 ? > Do we need to rebuild it ? No, sorry my mistake, my repoquery by default don't have rpmfusion-(non)free-updates ... (In reply to comment #5) > it works for me in F23 with xv-3.10a.jumbopatch.20070520-23.fc23, but this > version is not build in F22 Sorry, still there with xv-3.10a.jumbopatch.20070520-23, xv hangs on SIGQUIT. Fedora 22 has been EOL-ed and RPMFusion will no longer be releasing updates for this version of Fedora. This bug will be set to RESOLVED:EXPIRED at the end of the week to reflect this. If the problem persists after upgrading to the latest version of Fedora, please update the version field of this bug (and re-open it if it has been closed). Upgraded to F23 recently: confirmed this bug persists in F23. Fedora 23 has been EOL-ed and RPMFusion will no longer be releasing updates for this version of Fedora. This bug will be set to RESOLVED:EXPIRED at the end of the week to reflect this. If the problem persists after upgrading to the latest version of Fedora, please update the version field of this bug (and re-open it if it has been closed). Upgraded to F24 recently: confirmed this bug persists in F24. Fedora 23 will be EOL-ed this week and RPMFusion will no longer be releasing updates for this version of Fedora. This bug will be set to RESOLVED:EXPIRED next weekend to reflect this. If the problem persists after upgrading to the latest version of Fedora, please update the version field of this bug (and re-open it if it has been closed). Bug persists in F26 that I just upgraded to. (In reply to Trevor Cordes from comment #14) > Bug persists in F26 that I just upgraded to. The rpmfusion xv maintainer appears to be MIA so without someone (or you) submitting a patch to fix the issue it is unlikely to be fixed. (In reply to leigh scott from comment #15) > (In reply to Trevor Cordes from comment #14) > > Bug persists in F26 that I just upgraded to. > > The rpmfusion xv maintainer appears to be MIA OK, I guess I deserved that :) However... > so without someone (or you) > submitting a patch to fix the issue it is unlikely to be fixed. I think having xv in rpmfusion is useful to a lot of people (it is very useful to me at least). I am happy to handle packaging issues, and apply patches if/when they become available. However, I don't have the cycles to do maintenance and debugging on the software itself. At least not for use cases I don't personally run into on a regular basis... So you're right -- if anyone comes up with a patch, please send it to me, and I'll happily apply it! Cheers, --Gabriel I've poked around a bit but the code to handle the signals in C is beyond my capability and I couldn't spot what might be causing it. I might have another go some other time, but it'll probably take someone better versed than me. The thing that bugs me the most is that this feature used to work fine without exhibiting this bug and the it popped up suddenly though nothing changed in xv! That means it's some weird deep-down linux or X thing or something that changed. (In reply to Trevor Cordes from comment #17) > I've poked around a bit but the code to handle the signals in C is beyond my > capability and I couldn't spot what might be causing it. I might have > another go some other time, but it'll probably take someone better versed > than me. The thing that bugs me the most is that this feature used to work > fine without exhibiting this bug and the it popped up suddenly though > nothing changed in xv! That means it's some weird deep-down linux or X > thing or something that changed. Could you try testing https://koji.rpmfusion.org/koji/buildinfo?buildID=6221 You might need to rebuild the srpm for whichever fedora version you are using. (In reply to leigh scott from comment #18) > Could you try testing https://koji.rpmfusion.org/koji/buildinfo?buildID=6221 Thanks for working on this! I tried it on F26, and it does indeed fix the described symptoms. Trevor, how about you? You should probably have left out "Hopefully" from the changelog entry :) Leigh: yes it fixes the bug!! Thank you so much. This is superb, I thought it would never be fixed, and it was beyond my capabilities. I will definitely be checking out what the fix was in the code... When you push the fix, can it be pushed for F26 also? That's what I'm still (had to recompile src as you said). Though I could wait until I do F27 or 28. Another 6 months won't kill me :-) Interested in tackling a redraw bug that's been in there for 4-8 years too? I could open a new bz for it... :-) If that bug was fixed too xv would go back to being flawless! Thanks for fixing this. Fedora 26. $ grep xv * geo-map: debug 0 "You need to install 'xv', the best image viewer for Unix/Linux" Reading the latest comments, it seems fixed closing the bug , please reopen it , if I'm not correct. |
xv has a feature that if you send its process a SIGQUIT it will act as though the user pressed ENTER in the image window: it will reload the current image. I've used this for years and it worked great. Many years ago something broke with it though. I'm not sure if it was a change in xv or a change in linux. Now if you SIGQUIT xv will hang consuming 100% CPU unless certain steps are taken first. It will not hang if you map the info window (press i in main window) before the SIGQUIT (perhaps more things will workaround the bug too, but this is the only one I have found): Note, using the cmd line option -imap to map info does not work, you must do it by user interaction. Once you've manually mapped info, the bug disappears for all subsequent SIGQUITs, as many as you would like to send. It's like something important gets initialized on the user opening info. I also just found another workaround: manually resize the image first, for instance press , (comma) in the main window. Perhaps it is any main window user interaction that fixes the bug. To test (in tcsh syntax, bash might be similar or different) xv imagefile.jpg kill -QUIT %1 <hangs> To see that it is hung, try doing something in the window. When it hangs, strace shows: restart_syscall(<... resuming interrupted call ...>) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=5573, si_uid=500} --- poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"\207\10\7\0\0\1\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0", 28}, {NULL, 0}, {"", 0}], 3) = 28 <<<nothing else>>> When it works the strace at the same point shows: restart_syscall(<... resuming interrupted call ...>) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) --- SIGQUIT {si_signo=SIGQUIT, si_code=SI_USER, si_pid=5573, si_uid=500} --- poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{"\31\0\v\0)\0\300\2\0\0\0\0\2$\0\0\0\0\0\0T\2\0\0)\0\300\2\0\0\0\0"..., 44}, {NULL, 0}, {"", 0}], 3) = 44 sigreturn() (mask []) = -1 EINTR (Interrupted system call) poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) recv(3, "\202$\344\35\0\0\0\0T\2\0\0)\0\300\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0", 4096, 0) = 32 recv(3, 0x9911af0, 4096, 0) = -1 EAGAIN (Resource temporarily unavailable) [...]