Fix Linux test failures about quamash HOT 17 CLOSED

@harvimt You could add me to the team, and assign this issue to me.

from quamash.

I think this might have to do with Python 3.4.2, since I'm getting errors even on Windows after upgrading to this version.

from quamash.

I've fixed Linux problems locally, but tests still time out on Travis :( Since Travis builds are so darn slow, I've mailed Travis to find out how to debug interactively within their environment.

from quamash.

We need to set it up so it doesn't rebuild pyside every time it runs the
tests, that should make the Travis tests run much faster. (Build a wheel,
and install the wheel)

PySide has wheels in pypi but they're only for windows (and maybe OS X).

Other than that, it should be possible to run a travis instance locally
(that is unlikely to help though, but maybe worth a shot.)

On Sun, Dec 7, 2014 at 3:36 AM, Arve Knudsen [email protected]
wrote:

I've fixed Linux problems locally, but tests still time out on Travis :(
Since Travis builds are so darn slow, I've mailed Travis to find out how to
debug interactively within their environment.

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

Yeah, I haven't looked into the whole wheel building business. I can imagine it'll be more tricky on Linux than on Windows.

I have looked into running a Travis instance locally. Apparently, you need Vagrant and some Chef recipe. I haven't figured out the last part, but I'm hoping Travis support will help me out.

from quamash.

the tests still hang for me locally.

I'll see what I can find.

On Sun, Dec 7, 2014 at 4:31 AM, Arve Knudsen [email protected]
wrote:

Yeah, I haven't looked into the whole wheel building business. I can
imagine it'll be more tricky on Linux than on Windows.

I have looked into running a Travis instance locally. Apparently, you need
Vagrant and some Chef recipe. I haven't figured out the last part, but I'm
hoping Travis support will help me out.

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

ok, so I cannot get the tests to pass under any circumstances I can easily
test on linux.

For different reasons I need a 32bit python testing installation so I might
set that up.

regardless of Qt implementation or whether it's in an environment or not,
the subprocess tests always fail.

On Sun, Dec 7, 2014 at 2:11 PM, Mark Harviston [email protected] wrote:

the tests still hang for me locally.

I'll see what I can find.

On Sun, Dec 7, 2014 at 4:31 AM, Arve Knudsen [email protected]
wrote:

Yeah, I haven't looked into the whole wheel building business. I can
imagine it'll be more tricky on Linux than on Windows.

I have looked into running a Travis instance locally. Apparently, you
need Vagrant and some Chef recipe. I haven't figured out the last part, but
I'm hoping Travis support will help me out.

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

I have created a PySide wheel that works on Travis now. I also got a temporary debug Travis VM, which I'm logged onto right now and have just reproduced the issue.

from quamash.

I found that QSocketNotifier was triggering for sockets that were no longer monitored, so I added some logic to ignore such invalid notifications. This helps a bit in that socket reader callbacks aren't invoked when they shouldn't, but the test still hangs. The reason for the hang AFAICT (on my MacBook, since it reproduces here as well) is that the SubprocessProtocol isn't notified when the child process exits.

from quamash.

haha, yeah I learned I needed to compile with --standalone after I pushed
that wheel (which is still compiling, my laptop went to sleep and it
stalled the build process so I had to start over)

would it behoove us to reimplement BaseEventLoop.subprocess_exec in terms
of QProcess? (implementing subprocess_shell might be harder)

might even be able to get rid of some of the windows specific proactor
stuff (at the expense of more code size)

Then again we'd still need all the selector/file descriptor stuff to handle
sockets (unless those were reimplemented in terms of
QAbstractSocket/QIoDevice?)

On Mon, Dec 8, 2014 at 8:47 AM, Arve Knudsen [email protected]
wrote:

I have created a PySide wheel that works on Travis now. I also got a
temporary debug Travis VM, which I'm logged onto right now and have just
reproduced the issue.

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

Well, you don't need standalone. As you can see from my build, it works well at this time.

I don't see any reason right now why we would want to reimplement subprocess_exec? I mean, it ought to just work. There's probably some tiny detail causing the process exit not to be caught.

from quamash.

Yeah it was just a thought, but after perusing the code, I'm seeing how
much stuff would have to be implemented, it's probably not worth it since
it's probably some loose screw somewhere.

with regards to my build not working in travis, I bet it's a Qt version
mismatch or something.

I'm on ArchLinux so it's always the absolute newest version of every
package, and if you're on mint and Travis uses Debian or Ubuntu then it's
more likely for the stuff to "just work", so I'll see if your build works
on my machine or not, meanwhile I'm trying to build pyside on my machine
for the third time. :-)

On Mon, Dec 8, 2014 at 1:10 PM, Arve Knudsen [email protected]
wrote:

Well, you don't need standalone. As you can see from my build
https://travis-ci.org/aknuds1/quamash/builds/43379456, it works well at
this time.

I don't see any reason right now why we would want to reimplement
subprocess_exec? I mean, it ought to just work. There's probably some tiny
detail causing the process exit not to be caught.

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

I built the wheel using the same Ubuntu as Travis, i.e. 12.04.

On Mon, Dec 8, 2014 at 10:39 PM, Mark Harviston [email protected]
wrote:

Yeah it was just a thought, but after perusing the code, I'm seeing how
much stuff would have to be implemented, it's probably not worth it since
it's probably some loose screw somewhere.

with regards to my build not working in travis, I bet it's a Qt version
mismatch or something.

I'm on ArchLinux so it's always the absolute newest version of every
package, and if you're on mint and Travis uses Debian or Ubuntu then it's
more likely for the stuff to "just work", so I'll see if your build works
on my machine or not, meanwhile I'm trying to build pyside on my machine
for the third time. :-)

On Mon, Dec 8, 2014 at 1:10 PM, Arve Knudsen [email protected]
wrote:

Well, you don't need standalone. As you can see from my build
https://travis-ci.org/aknuds1/quamash/builds/43379456, it works well
at
this time.

I don't see any reason right now why we would want to reimplement
subprocess_exec? I mean, it ought to just work. There's probably some
tiny
detail causing the process exit not to be caught.

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

ok, so on UNIX systems the SIGCHLD (17) is used to notify when a child
process completes (or you can use os.waitpid w/ WNOHANG).

what happens is the the signal number is put on a self socket (_ssock) to
be read by _process_self_data which then calls _handle_signal
_handle_signal calls the signal handler for that signal wrapped in side a
Handle that is handled to _add_callback_signalsafe
ok so far so good.

but then the callbacks added by _add_callback_signalsafe are never fired
which never notifies the ChildWatcher etc.

what I did was
have _add_callback_threadsafe call call_soon_threadsafe with the super
call_soon_threadsafe.
this adds like 3 event loop iterations in order to complete.

Now I can wait on a process to complete, but cannot communicate with that
process via stdin/stdout.

maybe. the tests also seem like they might be kinda flaky.

On Mon, Dec 8, 2014 at 1:47 PM, Arve Knudsen [email protected]
wrote:

I built the wheel using the same Ubuntu as Travis, i.e. 12.04.

On Mon, Dec 8, 2014 at 10:39 PM, Mark Harviston [email protected]

wrote:

Yeah it was just a thought, but after perusing the code, I'm seeing how
much stuff would have to be implemented, it's probably not worth it
since
it's probably some loose screw somewhere.

with regards to my build not working in travis, I bet it's a Qt version
mismatch or something.

I'm on ArchLinux so it's always the absolute newest version of every
package, and if you're on mint and Travis uses Debian or Ubuntu then
it's
more likely for the stuff to "just work", so I'll see if your build
works
on my machine or not, meanwhile I'm trying to build pyside on my machine
for the third time. :-)

On Mon, Dec 8, 2014 at 1:10 PM, Arve Knudsen [email protected]
wrote:

Well, you don't need standalone. As you can see from my build
https://travis-ci.org/aknuds1/quamash/builds/43379456, it works
well
at
this time.

I don't see any reason right now why we would want to reimplement
subprocess_exec? I mean, it ought to just work. There's probably some
tiny
detail causing the process exit not to be caught.

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

nope just flaky

your implementation of _add_callback_signalsafe never works (that used
__wake_on_socket), but the default version only works maybe 3/4 of the time
(regardless of whether it's called directly, with call_soon_threadsafe, or
with call_soon.)

On Sat, Dec 13, 2014 at 8:58 PM, Mark Harviston [email protected] wrote:

ok, so on UNIX systems the SIGCHLD (17) is used to notify when a child
process completes (or you can use os.waitpid w/ WNOHANG).

what happens is the the signal number is put on a self socket (_ssock) to
be read by _process_self_data which then calls _handle_signal
_handle_signal calls the signal handler for that signal wrapped in side a
Handle that is handled to _add_callback_signalsafe
ok so far so good.

but then the callbacks added by _add_callback_signalsafe are never fired
which never notifies the ChildWatcher etc.

what I did was
have _add_callback_threadsafe call call_soon_threadsafe with the super
call_soon_threadsafe.
this adds like 3 event loop iterations in order to complete.

Now I can wait on a process to complete, but cannot communicate with that
process via stdin/stdout.

maybe. the tests also seem like they might be kinda flaky.

On Mon, Dec 8, 2014 at 1:47 PM, Arve Knudsen [email protected]
wrote:

I built the wheel using the same Ubuntu as Travis, i.e. 12.04.

On Mon, Dec 8, 2014 at 10:39 PM, Mark Harviston [email protected]

wrote:

Yeah it was just a thought, but after perusing the code, I'm seeing how
much stuff would have to be implemented, it's probably not worth it
since
it's probably some loose screw somewhere.

with regards to my build not working in travis, I bet it's a Qt version
mismatch or something.

I'm on ArchLinux so it's always the absolute newest version of every
package, and if you're on mint and Travis uses Debian or Ubuntu then
it's
more likely for the stuff to "just work", so I'll see if your build
works
on my machine or not, meanwhile I'm trying to build pyside on my
machine
for the third time. :-)

On Mon, Dec 8, 2014 at 1:10 PM, Arve Knudsen [email protected]

wrote:

Well, you don't need standalone. As you can see from my build
https://travis-ci.org/aknuds1/quamash/builds/43379456, it works
well
at
this time.

I don't see any reason right now why we would want to reimplement
subprocess_exec? I mean, it ought to just work. There's probably some
tiny
detail causing the process exit not to be caught.

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

huzzah!

I think I have the solution.

You were getting notifiers that should have been disabled but were firing
anyway, I have now disabled them instead of just logging them, so they
don't keep firing. seems to be some sort of problem with all those event
firings clogging up the loop, so the child process notification never fires
(except sometimes, hence flakiness).

It'll take awhile to tame this into a series of sensible commits and
discard all the debug statements.

On Sat, Dec 13, 2014 at 9:40 PM, Mark Harviston [email protected] wrote:

nope just flaky

your implementation of _add_callback_signalsafe never works (that used
__wake_on_socket), but the default version only works maybe 3/4 of the time
(regardless of whether it's called directly, with call_soon_threadsafe, or
with call_soon.)

On Sat, Dec 13, 2014 at 8:58 PM, Mark Harviston [email protected]
wrote:

ok, so on UNIX systems the SIGCHLD (17) is used to notify when a child
process completes (or you can use os.waitpid w/ WNOHANG).

what happens is the the signal number is put on a self socket (_ssock) to
be read by _process_self_data which then calls _handle_signal
_handle_signal calls the signal handler for that signal wrapped in side a
Handle that is handled to _add_callback_signalsafe
ok so far so good.

but then the callbacks added by _add_callback_signalsafe are never fired
which never notifies the ChildWatcher etc.

what I did was
have _add_callback_threadsafe call call_soon_threadsafe with the super
call_soon_threadsafe.
this adds like 3 event loop iterations in order to complete.

Now I can wait on a process to complete, but cannot communicate with that
process via stdin/stdout.

maybe. the tests also seem like they might be kinda flaky.

On Mon, Dec 8, 2014 at 1:47 PM, Arve Knudsen [email protected]
wrote:

I built the wheel using the same Ubuntu as Travis, i.e. 12.04.

On Mon, Dec 8, 2014 at 10:39 PM, Mark Harviston <
[email protected]>
wrote:

Yeah it was just a thought, but after perusing the code, I'm seeing
how
much stuff would have to be implemented, it's probably not worth it
since
it's probably some loose screw somewhere.

with regards to my build not working in travis, I bet it's a Qt
version
mismatch or something.

I'm on ArchLinux so it's always the absolute newest version of every
package, and if you're on mint and Travis uses Debian or Ubuntu then
it's
more likely for the stuff to "just work", so I'll see if your build
works
on my machine or not, meanwhile I'm trying to build pyside on my
machine
for the third time. :-)

On Mon, Dec 8, 2014 at 1:10 PM, Arve Knudsen [email protected]

wrote:

Well, you don't need standalone. As you can see from my build
https://travis-ci.org/aknuds1/quamash/builds/43379456, it works
well
at
this time.

I don't see any reason right now why we would want to reimplement
subprocess_exec? I mean, it ought to just work. There's probably
some
tiny
detail causing the process exit not to be caught.

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.

Sounds weird, but who knows. Haven't the time to look into it myself at the
moment, struggling with Emscripten, plus I need to put some hours into my
main project.

Arve

On Sun, Dec 14, 2014 at 12:07 PM, Mark Harviston [email protected]
wrote:

huzzah!

I think I have the solution.

You were getting notifiers that should have been disabled but were firing
anyway, I have now disabled them instead of just logging them, so they
don't keep firing. seems to be some sort of problem with all those event
firings clogging up the loop, so the child process notification never
fires
(except sometimes, hence flakiness).

It'll take awhile to tame this into a series of sensible commits and
discard all the debug statements.

On Sat, Dec 13, 2014 at 9:40 PM, Mark Harviston [email protected]
wrote:

nope just flaky

your implementation of _add_callback_signalsafe never works (that used
__wake_on_socket), but the default version only works maybe 3/4 of the
time
(regardless of whether it's called directly, with call_soon_threadsafe,
or
with call_soon.)

On Sat, Dec 13, 2014 at 8:58 PM, Mark Harviston [email protected]
wrote:

ok, so on UNIX systems the SIGCHLD (17) is used to notify when a child
process completes (or you can use os.waitpid w/ WNOHANG).

what happens is the the signal number is put on a self socket (_ssock)
to
be read by _process_self_data which then calls _handle_signal
_handle_signal calls the signal handler for that signal wrapped in side
a
Handle that is handled to _add_callback_signalsafe
ok so far so good.

but then the callbacks added by _add_callback_signalsafe are never
fired
which never notifies the ChildWatcher etc.

what I did was
have _add_callback_threadsafe call call_soon_threadsafe with the super
call_soon_threadsafe.
this adds like 3 event loop iterations in order to complete.

Now I can wait on a process to complete, but cannot communicate with
that
process via stdin/stdout.

maybe. the tests also seem like they might be kinda flaky.

On Mon, Dec 8, 2014 at 1:47 PM, Arve Knudsen [email protected]

wrote:

I built the wheel using the same Ubuntu as Travis, i.e. 12.04.

On Mon, Dec 8, 2014 at 10:39 PM, Mark Harviston <
[email protected]>
wrote:

Yeah it was just a thought, but after perusing the code, I'm seeing
how
much stuff would have to be implemented, it's probably not worth it
since
it's probably some loose screw somewhere.

with regards to my build not working in travis, I bet it's a Qt
version
mismatch or something.

I'm on ArchLinux so it's always the absolute newest version of every
package, and if you're on mint and Travis uses Debian or Ubuntu then
it's
more likely for the stuff to "just work", so I'll see if your build
works
on my machine or not, meanwhile I'm trying to build pyside on my
machine
for the third time. :-)

On Mon, Dec 8, 2014 at 1:10 PM, Arve Knudsen <
[email protected]>

wrote:

Well, you don't need standalone. As you can see from my build
https://travis-ci.org/aknuds1/quamash/builds/43379456, it works
well
at
this time.

I don't see any reason right now why we would want to reimplement
subprocess_exec? I mean, it ought to just work. There's probably
some
tiny
detail causing the process exit not to be caught.

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

—
Reply to this email directly or view it on GitHub
#8 (comment).

from quamash.