Opened 10 years ago

Closed 10 years ago

#70 closed defect (fixed)

Standard I/O streams of non-kLIBC based processes are not properly redirected

Reported by: dmik Owned by:
Priority: blocker Milestone: Qt Beta 3
Component: QtCore Version: 4.5.1 Beta 1
Severity: Keywords:


If QProcess starts an application that isn't based on the same (kLIBC) runtime as Qt4 itself, its standard streams are not properly redirected and cannot be accessed in the parent process.

This needs to be fixed. See #69 for more info.

Attachments (1) (1.8 KB) - added by dmik 10 years ago.
socketpair inheritance example

Download all attachments as: .zip

Change History (17)

comment:1 Changed 10 years ago by diver

i really hope we find a solution to this beside changing everything to native pipes. as i guess this would make a lot of work and it's less Qt standard like. fixing klibc maybe?

comment:2 Changed 10 years ago by dmik

I will invest some time into this after the beta. See my comment in #71 too.

Changed 10 years ago by dmik

socketpair inheritance example

comment:3 Changed 10 years ago by dmik

The attached program proves that inheritance of sockets created with socketpair() is broken in the current kLBC (0.6.3). No matter if we use stdio redirection (parent.exe started w/o arguments) or pass fd to child.exe in arguments (parent.exe started with any argument), child.exe sometimes fails to write to the stdout stream with the following error (approximately on every 10-20'th run):

CHILD ERROR: write: Socket operation on non-socket (38)

and nothing appears on the parent's end of the pipe.

This really looks like a deadlock. Studying kLIBC sources...

comment:4 Changed 10 years ago by dmik

By deadlock I mean race condition of course.

comment:5 Changed 10 years ago by dmik

I have no idea why the related comments went to ticket:72, but just for the record. The stdio redirection in QProcess seems to work well now. What about error 38, it disappears in my virtualized environment after I increase the child startup timeout in kLIBC. See ticket:72 (especially comments 17) for more details. This timeout question will be further tracked in this defect.

comment:6 Changed 10 years ago by dmik

That may be related to the fact that the windowed console output is really slow in OS/2 and either mplayer/smplayer may not expect such big delays. Let's keep an eye on that problem. If it's something different, it'll show up and we will look at it again.

comment:7 Changed 10 years ago by dmik

Argh, I just realized that all the LIBC socket/pipe hassle was in vain. Sh*t, I already knew that but something prevented me from thinking this up to the end.

We will have to use native pipes because otherwise only stdio of kLIBC-based applications may be redirected: programs using other libraries know nothing about kLIBC file descriptors, their inheritance and redirection. While native pipes operate on native file handles and thus always work. Too pity but at least we learned a lot of useful information about kLIBC which will help us later.

Starting to code the native pipe way.

comment:8 Changed 10 years ago by dmik

BTW, I've done some stress tests using kLIBC socket redirection (child reads a 29 MB file and writes it to stdout, parent reads it and writes back to the file): no distortions and the speed is within the limits.

comment:9 Changed 10 years ago by diver

  • Milestone changed from Qt GA to Qt Beta 3

comment:10 Changed 10 years ago by dmik

Done with native pipes in r197. It now works as expected: standard streams of all programs (e.g. cmd.exe) are now properly redirected. I'll do a bit of stress testing tomorrow++ before closing this defect.

comment:11 Changed 10 years ago by dmik

Cool, smplayer started working (i.e. is able to control mplayer playback now) immediately after this change.

The only thing that differs from the standalone mplayer runs (which are I remind jerky under VirtualBox?) is the flicker when the video goes to the Qt window. And also an attempt to close the GUI now gives this:

Debug: Core::stopMplayer: Waiting mplayer to finish...

Warning: QMutex::lock: Deadlock detected in thread 1

Looks like a non-recursive mutex is called recursively in smplayer code.

comment:12 Changed 10 years ago by dmik

This is actually a QProcess fault, will fix it.

comment:13 Changed 10 years ago by diver

ok great. as smplayer worked with older QProcess also for me i will wait till you fixed the above error. After that i will build Qt also new and try with my smplayer.

comment:14 Changed 10 years ago by dmik

The deadlock is fixed in r198 (I optimized the code so it doesn't need a lock at all in that place).

comment:15 Changed 10 years ago by dmik

Feeding data to the process' standard input stream now works (r203). BTW, I've created source:/tests to store various Qt4 testing applications (such as the one for QProcess).

comment:16 Changed 10 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed

Implemented QProcess->QProcess redirection (took a while to test, debug and fix oddities).

Now I consider this task to be done. Functionally wise, we are as good as other platforms.

Note: See TracTickets for help on using tickets.