<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Eric,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 4/1/22 13:55, Eric Pouech wrote:<br>
</div>
<blockquote type="cite"
cite="mid:986367a4-69c7-599b-3115-d51b438a5d35@orange.fr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Le 31/03/2022 à 20:16, Alexandre
Julliard a écrit :<br>
</div>
<blockquote type="cite" cite="mid:87ilrung27.fsf@wine">
<pre class="moz-quote-pre" wrap="">Francois Gouget <a class="moz-txt-link-rfc2396E" href="mailto:fgouget@codeweavers.com" moz-do-not-send="true"><fgouget@codeweavers.com></a> writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Signed-off-by: Francois Gouget <a class="moz-txt-link-rfc2396E" href="mailto:fgouget@codeweavers.com" moz-do-not-send="true"><fgouget@codeweavers.com></a>
That's great. I can now reproduce these failures.
The easiest way to do so from a terminal is something like this:
nohup ./wine ... 2>&1 | cat
With this winetest patch user32:input succeeds... sometimes.
I don't think this means the patch is wrong.
Rather the issue is that user32:input itself 'forks' without passing
DETACHED_PROCESS to CreateProcess(), causing consoles to appear in the
middle of the test which randomly leads to failures.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Do these consoles also appear on Windows then?
</pre>
</blockquote>
<p><font face="Helvetica, Arial, sans-serif">basically we should
have the following hierarchy of processes (for a testbot
invocation)<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif"> testagentd
Unix/windows<br>
\- TestLauncher (CUI)<br>
\- unit test (CUI)<br>
\- unit test can recurse upon itself (CUI)<br>
<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">according to
<a class="moz-txt-link-freetext"
href="https://testbot.winehq.org/JobDetails.pl?Key=111732&f201=exe64.report&f301=task.log#k301"
moz-do-not-send="true">https://testbot.winehq.org/JobDetails.pl?Key=111732&f201=exe64.report&f301=task.log#k301</a></font></p>
<p><font face="Helvetica, Arial, sans-serif">(it's a program to
output various information about console (attached / detached,
other processes attached to console, user32 information about
console, info about std handles...)</font></p>
<p><font face="Helvetica, Arial, sans-serif">the info is written
using various ways (prefix gives the way: w> using
write(1), W> using WriteFile(STD_OUTPUT_HANDLE), d>
wine_dbg_output...)</font></p>
<p><font face="Helvetica, Arial, sans-serif"><br>
</font></p>
<p>a) when the console is created</p>
<p>under Windows, the console is created when TestLaunched is
spawned. Seems logical: first CUI process, testagentd is likely
run detached.</p>
<p>in wine env, the console is created at least for the unit test
(test as written cannot get information from testlauncher back)</p>
<p>as testagentd (on unix) is likely detached (from unix tty),
TestLauncher is then created detached from unix but also windows
standpoint ; meaning the the w-console is only created for unit
test.</p>
<p>in both cases, the respawn from within the unit test should
reuse the same console</p>
<p>b) it then means that the unit test (because it's launched with
console creation) does not (currently) honor the std handle
inheritance (hence providing different output information)<br>
</p>
<p>that would explain the discrepancies on output prefix (windows
with wW> as those handles are inherited from TestLauncher),
and wine (d> using unix fd 1)</p>
<p>(under the assumption that in both wine and windows the
redirection for running a tests are done in a similar way)</p>
</blockquote>
<p><br>
</p>
<p>Nice, that explains the situation.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:986367a4-69c7-599b-3115-d51b438a5d35@orange.fr">
<p>we exchanged with Jacek what to do when wine foo is started as
initial wine process and foo is a CUI </p>
<p>on one hand, it would be a bad idea to let CreateProcess create
a console. cases when script is run in a headless context, or
detached from any tty...<br>
</p>
<p>on the other hand (as this case shows), not creating a console
is not always the best situation<br>
</p>
</blockquote>
<p><br>
</p>
<p>Yeah, that solution is not perfect, but it seems to me that there
is no solution that could satisfy both cases out of the box.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:986367a4-69c7-599b-3115-d51b438a5d35@orange.fr">
<p> </p>
<p>from these considerations, I would recommand that we mimic
windows' behavior: when run under wine only, testagend should
spawn TestLauncher with wineconsole (we know we can force a
user32/wine console creation): </p>
<p>./wine wineconsole TestLauncher... (instead of ./wine
TestLauncher)</p>
<p><br>
</p>
<p>François: what would be the best way to do it? (tweaking
platform_unix/platform_run() seems to be more widely used than
just running wine?</p>
</blockquote>
<p><br>
</p>
<p>One other solution that we may consider is to build tests as GUI
applications and add AttachConsole(ATTACH_PARENT_PROCESS) to
main() in test.h. That should preserve desired behaviour. We'd
probably need an opt-out mechanism for console tests, but it
should be fine otherwise, unless I'm missing something.</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Jacek<br>
</p>
</body>
</html>