> Em 5 de fev. de 2021, à(s) 04:33, Willy Tarreau <[email protected]> escreveu:
>
> On Wed, Feb 03, 2021 at 06:32:33PM -0300, Joao Morais wrote:
>>
>> Hello William, here[1] is some context. I implemented a parsing of the
>> reload command sent to the master cli, leave it running for a while and got
>> an index out of bounds (in my code) this week.
>>
>> I'm using this lay out to parse the reload output:
>>
>> // 1 3 4 6
>> 8 8
>> //
>> 0.......|.......6.......|.......2.......|.......8.......|.......4.......|.......0.......|.......8
>> //
>> // #<PID> <type> <relative PID> <reloads>
>> <uptime> <version>
>> // 1 master 0 2
>> 0d00h01m28s 2.2.3-0e58a34
>> // # workers
>> // 3 worker 1 0
>> 0d00h00m00s 2.2.3-0e58a34
>> // # old workers
>> // 2 worker [was: 1] 1
>> 0d00h00m28s 2.2.3-0e58a34
>> // # programs
>> //
>>
>> Apparently I found a line that: starting char isn't '#', have 32 chars or
>> more, have less than 48 chars. Is that even possible?
>
> I had a quick look at the code producing this output and it writes
> full lines at once, but the second one is a string which is mostly a
> constant ("worker", "master"), or taken from a structure for old
> programs. So I'm seeing two possibilities:
> - either your parser received an incomplete line due to network buffering
> and decided to parse it before getting the trailing "\n"; this is a
> pretty common issue in line-oriented parsers ported to consume data
> from other processes ;
>
> - or the process memory was corrupted so that an old program's "child->id"
> contained some crap and a "\n", which would have resulted in printing
> the PID, this crappy string, and the rest of the line on a second separate
> line.
>
> The last point seems pretty possible given that your outdated version is
> affected by 123 known bugs, 2 of which could cause memory corruption.
So we probably ended with the first one - currently using 2.2.8, this output
came from my drafts when I was designing the remote restart. =)
>> How would you expand the lay out above, so I can improve my parser and my
>> tests? Thanks!
>
> Please read the chunk_appendf() statements in cli_io_handler_show_proc(),
> they're pretty explicit and you'll get the exact output format for various
> types of dumps. But that's basically what's documented above, it's just
> that it may help you to figure some constants there (or that some fields
> are unsigned for example).
Thank you so much for the insight! This will help us to prepare the code for
such corner cases.
~jm
