[Bug 60123] New: OutputDebugStringA/W payloads truncated at ~300 bytes in +debugstr/+seh channel output
http://bugs.winehq.org/show_bug.cgi?id=60123 Bug ID: 60123 Summary: OutputDebugStringA/W payloads truncated at ~300 bytes in +debugstr/+seh channel output Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: souyamadebnath@gmail.com Target Milestone: --- Distribution: --- Applications that emit long strings via OutputDebugStringA/W have their payloads truncated in wine's debug channel output. Both WINEDEBUG=+debugstr (warn:debugstr:OutputDebugStringA "...") and WINEDEBUG=+seh (warn:seh:dispatch_exception "...") print at most ~300 bytes followed by `"...`, because wine_dbgstr_an/wine_dbgstr_wn (include/wine/debug.h) format into a fixed `char buffer[300]`. To Reproduce: call OutputDebugStringA with a 400-char string and run with WINEDEBUG=+debugstr. Output ends with `"...` after ~300 chars. 1. Compile this test program with mingw: ``` #include <windows.h> int main(void) { char buf[500]; for (int i = 0; i < 400; i++) buf[i] = 'A' + (i % 26); buf[400] = 0; OutputDebugStringA(buf); OutputDebugStringA("short line\r\n"); return 0; } ``` ``` $ x86_64-w64-mingw32-gcc dbg.c -o dbg.exe ``` 2. Run under wine with the debugstr channel: ``` $ WINEDEBUG=+debugstr wine ./dbg.exe ``` Actual output (400-char payload clipped at ~300, note the trailing `"...`): ``` 0024:warn:debugstr:OutputDebugStringA "ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDE"... 0024:warn:debugstr:OutputDebugStringA "short line\r\n" ``` Expected: the full 400-character string, as a debugger or DBWIN listener would receive on Windows. Same truncation occurs with WINEDEBUG=+seh (warn:seh:dispatch_exception). Side note on Windows behaviour: On Windows the full string is always delivered to consumers. A debugger attached via WaitForDebugEvent receives `OUTPUT_DEBUG_STRING_INFO` with the complete length (read via `ReadProcessMemory`), and `DBWIN_BUFFER` listeners (e.g. Sysinternals DebugView) receive up to 4 KiB per frame, with longer strings split across frames rather than dropped. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60123 Eric Pouech <eric.pouech@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com --- Comment #1 from Eric Pouech <eric.pouech@gmail.com> --- did you test that a debugger under Wine (like winedbg) gets a truncated string (to compare apples with apples)? the limitation you likely see in within the traces, where output is truncated to avoid some overflow (and bad behavior when strings are crippled); this won't be changed -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60123 Souyama <souyamadebnath@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |souyamadebnath@gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60123 --- Comment #2 from Souyama <souyamadebnath@gmail.com> --- Under winedbg it's truncated to 255 characters. I understand trying to avoid buffer overflow but I was under the impression that those WINEDEBUG flags were to capture debug log outputs. I am trying to replicate this behaviour of capturing game logs. OG Reference code: https://github.com/WFCD/WFinfo/blob/master/WFInfo/LogCapture.cs Which I am replicating by making my binary launch the game with the WINEDEBUG env var set first. Can't the buffer size be made adjustible via another env var? Or if to remain fixed size increase to 4096? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60123 --- Comment #3 from Souyama <souyamadebnath@gmail.com> --- Anyway it's still a bug that the message is truncated and lost, instead of say split across frames like how it's in Windows. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60123 --- Comment #4 from Eric Pouech <eric.pouech@gmail.com> --- fix to winedbg shall be included in https://gitlab.winehq.org/wine/wine/-/merge_requests/11586 (which raises limit to 65536) for the DBWIN* part (sending strings longer than 4k-4), it will require some more work on top of tentative patch attached for testing -likely tests- (in next comment) the WINEDEBUG channels are for debugging Wine, not for tracing every content application can use; so I'm afraid this is not the right solution for what you're trying to do -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60123 --- Comment #5 from Eric Pouech <eric.pouech@gmail.com> --- Created attachment 81695 --> http://bugs.winehq.org/attachment.cgi?id=81695 tentative patch for DBWin >4k-4 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla