Crash: urllib.urlretrieve() ConnectionTimeout causes worker to try to update GUI that is already closed

[Byron]

Tested with 0.1.5

urllib reads the http_proxy environment variable to auto-configure itself for proxy use. However, the widget is unaware of this fact, so it will offload url-retrievals to its worker thread. Those calls could see a 60 second timeout, which is enough for the worker to stay active longer than the parent GUI itself.

Once the call is completed, the error will be communicated to the now closed parent GUI, which caused Maya to crash during my tests. The crash would happen even with the queued-connections fix applied ( #1 ) .

Solutions

Tank receives information about proxy servers for connecting to shotgun, and the widget could use the same proxy by default when using the urllib, making tank configurations less error prone from behind a proxy.

I know that the browser_widget does indeed stop the worker, which should prevent it from emitting anything. However, it didn't work for me.

[manneohrstrom]

Sounds like if we just make sure that the proxy settings are picked up when we are looking for thumbnails, we should be okay. I'll create a ticket for this in our internal ticketing system! Thanks very much for reporting this!

What priority would you consider this being?

[Byron]

This one has very low priority, as it is now fixed on our side by setting the http_proxy variable.

Please try to reproduce the issue that completion events of long-running tasks for some reason end up being emitted to a GUI that by then does not exist anymore.

For that, you could use the Maya engine and use the asset loader to load an asset while the asset thumbnail is still being downloaded. When the task completes, maya will crash. When that happened, I could sometimes see messages like "QPIxmap was changed from a non-gui thread" created by QT.

This could be a hint to the destroy() method of either list item or browser widget is not called to stop the workers task execution.

[Byron]

Actually this issue is absolutely persistent. Whenever urlparse.retrieveurl fails, we see multi-threading related crashes, as the GUI is changed from a non-gui thread. The version we use is 0.1.4 . It doesn't make a difference whether or not one sets the connection to queued mode explicitly.

[alandann]

Hi Sebastian,

I'll take a look and see if I can reproduce this today.

Sorry this is causing you problems!

Thanks
Alan

[Byron]

Thank you ! The crash will also occur while the GUI is open.

To reproduce it, it should be enough to just throw an exception in place of the urlparse.retrieveurl() call. In our case, this will bring down maya (2012) right away.

[alandann]

Hmm, I'm not having much luck reproducing this - remind me, which OS you
are on?

Also, are you running a specific app to test this or have you set up an
isolated test - if it's an app, then which one as that might make a
difference.

Thanks
Alan

On Fri, Jul 26, 2013 at 9:03 AM, Sebastian Thiel
notifications@github.comwrote:

Thank you ! The crash will also occur while the GUI is open.

To reproduce it, it should be enough to just throw an exception in place
of the urlparse.retrieveurl() call. In our case, this will bring down maya
(2012) right away.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-21606864
.

[Byron]

We are using Centos 6.4, the app is the standard loader. Its important that it doesn't have everything cached, but tries to load a resource from the internet. We are digging into this and are discovering https-related limitations of urlparse when behind a proxy.
QT will print messages about its threading issues into the terminal, on windows this would be the maya output window I suppose.

[alandann]

Hi,

I just wanted to say that with the latest update we've changed the threading so that the it waits for the worker to finish before returning after stopping.

What was happening is that the underlying QThreadMutex object was getting cleaned up by Qt but would still try to be accessed by the python code.

We think this improves stability although you may now see a delay when closing the dialog if there is a thread that has hung for some reason.

Let us know if you still see crashes with the latest framework (v0.1.17) of if you have problems with it hanging.

Thanks
Alan