scrot -f -s - hangs and freezes the X server after selection

[Xenapte]

scrot -f -s - (outputting to stdout) from the latest commit hangs and freezes the X server when attempting to take larger screenshots. The only way to recover is by switching to a different tty and pkill scrot.

Steps to reproduce

• Compile scrot from the latest commit.
• Run scrot -f -s -.
• Select a large area for the screenshot.
• Observe that the X server freezes.

Additional context

I was using scrot -fs - | xclip ... to take area screenshots into my clipboard earlier when I noticed the issue described in [#381] (content captured by scrot -f -s differs from the content that is frozen on), and as there seemed to be a fix in [#382], I compiled scrot myself from latest commit and noticed the problem above. It also doesn't seem to output any logs.

[N-R-K]

Can't reproduce with with a 1080p resolution. Are you sure c60a26c is the culprit? Does it work before that commit?

But in any case, the current --freeze implementation though XGrabServer is really ugly. I have an idea on how to improve it. Basically, take a fullscreen screenshot right away, and then open a fullscreen window and display the shot while the user selects, once selection is done we crop the original shot. Only issue I can think of is that window selection will not work since our overlay window will be on top of everything.

[N-R-K]

Can't reproduce with with a 1080p resolution. Are you sure c60a26c is the culprit? Does it work before that commit?

Also when testing, try explicitly testing both --line 'mode=classic' and --line 'mode=edge' separately since before that commit --freeze never worked on edge mode.

[Xenapte]

I just tested again and it seems that scrot -fs itself is fine. It's outputting to stdout (scrot -fs -) that hangs it, no matter which line mode I have set. (for context: I'm chaining scrot with xclip to directly screenshot into my clipboard, so I have to use scrot -)

Also, I can confirm it's c60a26c - scrot compiled from the previous commit works fine.

[Xenapte]

I have updated the title to match my observation.

[N-R-K]

I have updated the title to match my observation.

Okay, thanks. I'm still not sure why that commit in specific would be causing this issue.

It's outputting to stdout (scrot -fs -) that hangs it

Does writing to a file work (e.g scrot -fs - >/tmp/shot.png)? Or is it specifically when piping to xclip?

If writing to a file works, then can you also test piping that file into xclip afterwards? E.g:

scrot -fs - >/tmp/shot.png
cat /tmp/shot.png | xclip ...

(Note, I'm using cat instead of stdin redirect to simulate an actual pipe).

Also please provide the full xclip command you're using.

[Xenapte]

Does writing to a file work (e.g scrot -fs - >/tmp/shot.png)? Or is it specifically when piping to xclip?

Writing to a file works for some reason.

Direct stdout output (just direct scrot -fs -) or piping into xclip doesn't work. My minimum xclip piping command is scrot -fs - | xclip -selection clipboard -t image/png.

[N-R-K]

Writing to a file works for some reason.

Okay. Weird.

scrot -fs - | xclip -selection clipboard -t image/png

I tried this out and took a 1080p shot and it worked fine. My xclip & X version:

$ xclip -version 
xclip version 0.13
$ X -version 
X.Org X Server 1.21.1.16
X Protocol Version 11, Revision 0

Are you using linux or some other OS? Maybe test out the v2 branch if you have sufficient version of imlib2, it contains some "fixes" to stdout handling.

[Xenapte]

I tried this out and took a 1080p shot and it worked fine.

1080p also (mostly) works fine for me, however my monitor is at 3072x1920. Maybe try taking something bigger? It's inconsistent too, maybe try filling your screen up with random patterns that maximizes the output image size?

Are you using linux or some other OS? Maybe test out the v2 branch

Yes, I'm on Linux. Unfortunately v2 still has the same problems, but it does seem to work more and hang less for some reason. The thing is, I don't know if this is related to CPU cache or something (my knowledge of hardware is super limited), but the more I use scrot, the less likely it hangs, so it is really hard to test everything out.

[Xenapte]

Also, in the meantime, I guess I'll just go with scrot -fs -F /tmp/scrot.png && xclip -selection clipboard -t image/png -i /tmp/scrot.png && rm /tmp/scrot.png for now - I'll report back if that also hangs.

[N-R-K]

It's inconsistent too

If it's inconsistent, then are you sure that it's c60a26c causing the issue and that you didn't just get lucky when trying the older commit?

Maybe try taking something bigger?

My monitor isn't any bigger :)

Also, in the meantime, I guess I'll just go with scrot -fs -F /tmp/scrot.png && xclip -selection clipboard -t image/png -i /tmp/scrot.png && rm /tmp/scrot.png for now - I'll report back if that also hangs.

If this also hangs then the issue is almost certainly with xclip and not scrot. So do report back.

[N-R-K]

scrot -fs -F /tmp/scrot.png && xclip -selection clipboard -t image/png -i /tmp/scrot.png && rm /tmp/scrot.png

I was going to say that you can also use scrot -fs -e 'xclip -selection clipboard -t image/png -i "$f"; rm -f "$f"' instead, but in trying to run that command myself, I was able to trigger the hang myself.

Hooking into the hanged process with gdb, I see that it's hanged in here:

scrot/src/scrot.c

Line 636 in 6345b81

int ret = system(execStr);

This means that stdout has nothing to do with the issue. I think it maybe due to the ungrab request not being flushed?? Does the following patch solve the issue for you? For me it seems to fix the problem, I can't trigger it anymore.

diff --git a/src/scrot_selection.c b/src/scrot_selection.c
index 1bb55db..d860e7b 100644
--- a/src/scrot_selection.c
+++ b/src/scrot_selection.c
@@ -451,8 +451,10 @@ Imlib_Image scrotSelectionSelectMode(void)
     Imlib_Image capture = scrotGrabRectAndPointer(
         rect0.x, rect0.y, rect0.w, rect0.h, opt.freeze);
 
-    if (opt.freeze)
+    if (opt.freeze) {
         XUngrabServer(disp);
+        XFlush(disp);
+    }
 
     if (opt.selection.mode == SELECTION_MODE_CAPTURE)
         return capture;

[Xenapte]

If it's inconsistent, then are you sure that it's c60a26c causing the issue and that you didn't just get lucky when trying the older commit?

scrot compiled from that commit onwards has a 70% or something chance to hang for me when I try to take a fullscreen screenshot. For the older commit I tried doing the same thing 20 times, and couldn't trigger anything. So I'd say I'm pretty sure here.

Does the following patch solve the issue for you?

$ git diff
──────────────────────────────────────────────────────
modified: src/scrot_selection.c
──────────────────────────────────────────────────────
@ src/scrot_selection.c:434 @ Imlib_Image scrotSelectionSelectMode(void)
    if (opt.delaySelection)
        scrotDoDelay();

-   if (opt.freeze)
+   if (opt.freeze) {
        XGrabServer(disp);
+       XFlush(disp);
+   }

    bool success = scrotSelectionGetUserSel(&rect0);
    if (success) {

Unfortunately no. I tried patching both the master and v2 branch and they all trigger the hang for me.

On a second note, I also tried scrot -fs -F /tmp/scrot.png && xclip -selection clipboard -t image/png -i /tmp/scrot.png && rm /tmp/scrot.png 20 times - it also worked just fine.

[N-R-K]

Unfortunately no. I tried patching both the master and v2 branch and they all trigger the hang for me.

That's not the correct patch. The XFlush needs to be added after XUngrabServer call, not Grab.

[Xenapte]

OK I don't know how I misread your patch, but after applying the correct one the problem is gone, or at least, I can't trigger it any more. Should we close this issue then?

[N-R-K]

but after applying the correct one the problem is gone, or at least, I can't trigger it any more.

Aright, so I guess that was it.

Should we close this issue then?

It'll be auto closed when #403 is merged.

[N-R-K]

I've merged the fix. Thanks for the report and the debugging.