http://qs321.pair.com?node_id=1173887


in reply to Re^11: sysread/syswrite wrappers
in thread sysread/syswrite wrappers

I took the stacktrace, on linux: Stacktrace starts with:
read(4, "abcdefghijklmnopqrstuvwxyz012345"..., 8192) = 6070 write(1, "01285168: 'abcdefghijklmnopqrstu"..., 7501285168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01285168: 'abcdefghijklmnopqrstu"..., 7501285168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01285168: 'abcdefghijklmnopqrstu"..., 7501285168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01285168: 'abcdefghijklmnopqrstu"..., 7501285168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75
You see that it reads 6070 bytes right in one single read. After that it reads nothing, only writes to the screen. But select indeed returns right filehandle. Okay, end of stacktrace:
select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01285168: 'abcdefghijklmnopqrstu"..., 7501285168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01285168: 'abcdefghijklmnopqrstu"..., 7501285168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01285168: 'This is the last line"..., 3401285168: 'This is t +he last line' ) = 34 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) read(4, "", 8192) = 0 close(3) = 0 close(4) = 0 rt_sigaction(SIG_0, NULL, {0x7fb26fce06b2, ~[RT_1 RT_2 RT_3 RT_4 RT_5 +RT_6 RT_7 RT_8 RT_9 RT_10 RT_11 RT_12 RT_13 RT_14 RT_15 RT_16 RT_17 R +T_18 RT_19 RT_20 RT_21 RT_22 RT_23 RT_24 RT_25 RT_26 RT_27 RT_28 RT_2 +9 RT_30 RT_31], 0}, 8) = -1 EINVAL (Invalid argument) rt_sigaction(SIGHUP, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGILL, NULL, {SIG_DFL, [], 0}, 8) = 0
select returns right filehandle again, and.. read returns EOF. So whole the time select was triggered by eof event (EOF is "can_read" too). Let's check. I added sleep before closing socket in client:
sleep; close $server;
and server hanged in the middle. So, without EOF event it stucks. New stacktrace:
ioctl(4, 0x8004667e, 0x1b77ff0) = -1 ENOTTY (Inappropriate ioc +tl for device) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) read(4, "abcdefghijklmnopqrstuvwxyz012345"..., 8192) = 1071 write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 [cut similar lines] select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL) = 1 (in [4]) read(4, "abcdefghijklmnopqrstuvwxyz012345"..., 8192) = 4999 write(1, "01d4c168: 'abcdefghijklmnopqrstu"..., 7501d4c168: 'abcdefghi +jklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ' ) = 75 select(0, NULL, NULL, NULL, {0, 100000}) = 0 (Timeout) select(8, [3 4], NULL, [3 4], NULL
last select is not finished. means process stuck on it.

Replies are listed 'Best First'.
Re^13: sysread/syswrite wrappers
by BrowserUk (Patriarch) on Oct 12, 2016 at 23:42 UTC
    select returns right filehandle again, and.. read returns EOF. So whole the time select was triggered by eof event (EOF is "can_read" too).

    In other words. IT WORKS!

    last select is not finished. means process stuck on it.

    You added a sleep to the client. Ergo: you created the exact scenario I warned you about in "And if your messages are not some exact multiple of 4K, the last line of every 4k block will be a partial message, and your wrapper will therefore block until the next 4k block has been filled and passed through, before that message will be completed.".

    The problem here is that you've latched onto something completely irrelevant, to distract from the fact that your OP code makes no sense.

    I was never suggesting that you should use <readline> & print; only that your code was exactly as vulnerable to the same issue -- an incomplete message, perpetual block -- as they are.

    Ie. If you added that sleep in the same place in the client code, and ran it against your OP sysread() wrapper, it blocks in exactly the same way!

    Your OP wrappers are useless, because they are vulnerable in exactly the same way as readline.

    And that's the point.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.
      In other words. IT WORKS!
      No. It does not. It hangs. Unless you reconnect every messages (close socket after every message and make new connections for new messages).
      that your code was exactly as vulnerable to the same issue -- an incomplete message, perpetual block -- as they are.
      Ie. If you added that sleep in the same place in the client code, and ran it against your OP sysread() wrapper, it blocks in exactly the same way!
      No. Your code hanged without printing "This is the last line". Mine would block in the same select, waiting new data (which will not come), but after printing "This is the last line".
      Ie. If you added that sleep in the same place in the client code, and ran it against your OP sysread() wrapper, it blocks in exactly the same way!
      No, but my code will block in case incomplete message (which will never happen, unless client is buggy), and your code hangs even in the middle of complete message: client sent complete message, but code read only half of it.
        It works. Until *YOU* fuck it up.

        Thick as two short planks.