pipes not created unique

[diver]

in qprocess_pm.cpp it's possible that pipes are not created unique. this leads to a problem if a new process is started with the same pipe key. the problem occured in smplayer.

see attached patch to qprocess_pm.cpp. it fixes the smplayer problem

[dmik]

Good catch, Silvan! Indeed, due to the delayed processing of the WM_I_PIPE_CLOSE message, it was possible that the pipe key would already refer to foreign pipe from another process started in the meantime.

However, the workaround you suggest has a small flaw: consider what happens if an application starts an ever running process that gets a pipe key equal to 1 and then starts many short-term processes that eventually cause the key to wrap over USHORT... It's rare but IMHO still quite possible for a long running application.

Instead, in r186, I attempted to fix the real problem -- by making sure the key is not used after the associated pipe is closed. Please check that it really works with smplayer and report here.

P.S. To say the all truth, the original idea of using the 32-bit pipe handle as a 16-bit key also has a potential flaw (the system may return a handle that uses more than low 16 bits) but the side effect will be less dramatic: Qt will simply refuse to start a process and return a failure from QProcess::start(). Anyway, if it ever happens, the proper solution is to use QFreeValueList from qeventloop_pm.cpp for managing unique key values for pipes.

[diver]

Dmik, i built a new qt dll and sent it to the person who discovered the orginal bug. according to him the new dll shows the same behaviour as the one from svn rev 185. The problem only occurs if one plays from a playlist in smplayer.the problem is an assertion, but it leads to a hang. most probably because mplayer writes to a pipe which does not exist anymore.

[diver]

this message is issued and after that mplayer dies Warning: ASSERT: "pipe->closed" in kernel/qprocess_pm.cpp (596)

this happens when the second mplayer was started from the playlist. could it be that a message was not cleared from the object window?

[dmik]

Ok, next question. Can you reproduce it yourself with process debugging enabled? We really should find out why exactly this happens.

[diver]

sure i can. i will build a new dll with process debugging enabled and attach the log here.

[diver]

in out1.tyt you see the ending of the first movie in the playlist. and the start of the next with the assert problem

[dmik]

We were missing some pipe close points in other places too. In r188, I attempted to fix the problem once more -- this time by processing all associated messages from the queue before closing the pipes.

[diver]

i did some limited testing and it seems to work. i sent the new dll to some other testers and if it works there also i will close the ticket

[diver]

this fix works like a charm. so the ticket can be closed