[PATCH] ntdll: Truncate and ellipsize debug output if it's too long.

[Alexandre Julliard]

"Esme Povirk (she/they)" <esme at codeweavers.com> writes:

> On Tue, Aug 31, 2021 at 5:03 AM Alexandre Julliard <julliard at winehq.org> wrote:
>> > I would still like to figure this out for the occasions when Mono
>> > produces really long trace outputs.
>>
>> The best is to send them through debugstr_a/w, but you can also truncate
>> or wrap them manually as seems appropriate. You don't need to know the
>> exact buffer length, you can use say 600 chars (two debugstr's worth).
>
> The trouble is that Mono likes to send debug output in pieces,
> especially the trace functionality where each argument is a single
> call to mono_print_handler_fn. To illustrate, I tried modifying it to
> print just one line with debugstr_a and got call traces like this:
>
> 00fc:fixme:mscoree:mono_print_handler_fn "ENTER:c (wrapper
> managed-to-native) System.IO.MonoIO:Write
> (intptr,byte[],int,int,System.IO.MonoIOError&)("
> 00fc:fixme:mscoree:mono_print_handler_fn "0000000000000014"
> 00fc:fixme:mscoree:mono_print_handler_fn ", "
> 00fc:fixme:mscoree:mono_print_handler_fn
> "[System.Byte[]:[1024]0000000001457a40]"
> 00fc:fixme:mscoree:mono_print_handler_fn ", "
> 00fc:fixme:mscoree:mono_print_handler_fn "0"
> 00fc:fixme:mscoree:mono_print_handler_fn ", "
> 00fc:fixme:mscoree:mono_print_handler_fn "15"
> 00fc:fixme:mscoree:mono_print_handler_fn ", "
> 00fc:fixme:mscoree:mono_print_handler_fn "[BYREF:000000000011f140]"
> 00fc:fixme:mscoree:mono_print_handler_fn ")\n"
>
> We could keep track of the total line length in some sort of TLS, but
> it feels like it'd be better to do that in the common debug code where
> we already have a TLS structure than in mscoree. There's also a
> possibility that the length stored by mscoree will be off if other
> Wine traces occur in the same thread between these calls (which would,
> of course, garble the output, so maybe that's an argument for having a
> string buffer in mscoree, but it doesn't feel very clean to me as we'd
> have to hard-code the maximum length).

It sounds very much like you want a buffer for mono_print_handler_fn
separate from the other debug functions. I don't see any issue with
hard-coding a maximum length.

-- 
Alexandre Julliard
julliard at winehq.org