Fatal python error when interacting with GUI while seperate thread is running

wxPython Users
1

Hello,

I have had an ongoing issue with using threading to create a non-blocking GUI application in wxPython. I am trying to do some image analysis that takes a few seconds per image, so I am using threading to do the processing with the goal of keeping my GUI from being unresponsive during the analysis. After I click the analyze button, if I interact at all with the GUI, I get a “Fatal Python error: UNREF invalid object” error. I have narrowed it down to one line in the new threads run() function. The problem occurs while the image is being “opened”, or in this case copied from a Swig API. The copy takes about 2 seconds and it is during this 2 second window that interacting with the GUI gives me the error. I tried put a Lock() around that particular operation, but I still got the same error. Any help/ideas would be greatly appreciated.

Thanks,
Ian

2

Is the thread trying to interact directly with wxpython? Also we can't help much more without seeing some code.

3

Hi Ian,

···

On Friday, July 11, 2014 12:53:59 PM UTC-5, Ian Abshire wrote:

Hello,

I have had an ongoing issue with using threading to create a non-blocking GUI application in wxPython. I am trying to do some image analysis that takes a few seconds per image, so I am using threading to do the processing with the goal of keeping my GUI from being unresponsive during the analysis. After I click the analyze button, if I interact at all with the GUI, I get a “Fatal Python error: UNREF invalid object” error. I have narrowed it down to one line in the new threads run() function. The problem occurs while the image is being “opened”, or in this case copied from a Swig API. The copy takes about 2 seconds and it is during this 2 second window that interacting with the GUI gives me the error. I tried put a Lock() around that particular operation, but I still got the same error. Any help/ideas would be greatly appreciated.

Thanks,
Ian

It sounds like you might be trying to call wxPython directly from the thread. You cannot do that. Instead you have to use one of wxPython’s thread-safe methods, such as wx.CallAfter or wx.PostEvent. Those allow you to call the UI from a thread without causing anything weird to happen. See also LongRunningTasks - wxPyWiki

  • Mike
4

Hi,

Thank you for your response. I should have mentioned, that was my first thought. I rewrote it so that the thread should not be interacting with wxPython. I am using wx.PostEvent in order to return the data to the main thread. I have attached a sample of the code to show where the issue is. In the Opener() class there is no reference to wx or the gui.

Thanks,
Ian

analyze_all_thread_sample.py (1.97 KB)

···

On Friday, July 11, 2014 11:41:39 AM UTC-7, Mike Driscoll wrote:

Hi Ian,

On Friday, July 11, 2014 12:53:59 PM UTC-5, Ian Abshire wrote:

Hello,

I have had an ongoing issue with using threading to create a non-blocking GUI application in wxPython. I am trying to do some image analysis that takes a few seconds per image, so I am using threading to do the processing with the goal of keeping my GUI from being unresponsive during the analysis. After I click the analyze button, if I interact at all with the GUI, I get a “Fatal Python error: UNREF invalid object” error. I have narrowed it down to one line in the new threads run() function. The problem occurs while the image is being “opened”, or in this case copied from a Swig API. The copy takes about 2 seconds and it is during this 2 second window that interacting with the GUI gives me the error. I tried put a Lock() around that particular operation, but I still got the same error. Any help/ideas would be greatly appreciated.

Thanks,
Ian

It sounds like you might be trying to call wxPython directly from the thread. You cannot do that. Instead you have to use one of wxPython’s thread-safe methods, such as wx.CallAfter or wx.PostEvent. Those allow you to call the UI from a thread without causing anything weird to happen. See also http://wiki.wxpython.org/LongRunningTasks

  • Mike
5

Hi,

Thank you for your response. That was my first thought, as well. I rewrote it so that the thread should not be interacting with wxPython. I am using wx.PostEvent in order to return the data to the main thread. I have attached a sample of the code to show where the issue is. In the Opener() class there is no reference to wx or the gui.

Thanks,
Ian

analyze_all_thread_sample.py (1.97 KB)

···

On Friday, July 11, 2014 11:32:59 AM UTC-7, Nathan McCorkle wrote:

Is the thread trying to interact directly with wxpython? Also we can’t help much more without seeing some code.

6

As far as I know, wx.MilliSleep is not thread-safe. You should just use Python’s time module instead.

  • Mike
···

On Friday, July 11, 2014 2:01:58 PM UTC-5, Ian Abshire wrote:

Hi,

Thank you for your response. I should have mentioned, that was my first thought. I rewrote it so that the thread should not be interacting with wxPython. I am using wx.PostEvent in order to return the data to the main thread. I have attached a sample of the code to show where the issue is. In the Opener() class there is no reference to wx or the gui.

Thanks,
Ian

7

Mike Driscoll wrote:

As far as I know, wx.MilliSleep is not thread-safe. You should just
use Python's time module instead.

I'm not sure how you could make MilliSleep not be thread-safe...

The source for wxMilliSleep consists of one line: a call to the Win32
Sleep API. It is most definitely thread-safe. It will, however, block
the current thread, so it's not wise to call it from your main GUI thread.

However, the advice to use the standard time module is still good. In
general, always use a standard library module when there is a
duplication of functionality.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

8

Tim,

···

On Friday, July 11, 2014 2:22:15 PM UTC-5, Tim Roberts wrote:

Mike Driscoll wrote:

As far as I know, wx.MilliSleep is not thread-safe. You should just

use Python’s time module instead.

I’m not sure how you could make MilliSleep not be thread-safe…

The source for wxMilliSleep consists of one line: a call to the Win32

Sleep API. It is most definitely thread-safe. It will, however, block

the current thread, so it’s not wise to call it from your main GUI thread.

However, the advice to use the standard time module is still good. In

general, always use a standard library module when there is a

duplication of functionality.

–
Tim Roberts, ti...@probo.com

Providenza & Boekelheide, Inc.

That’s good to know. I’ve never heard anyone mention wx.MilliSleep as thread-safe, but then again, I’ve barely seen anyone use it either.

Mike

9

I see, that is good to know. Although, wx.MilliSleep is just being used to separate the operations so I could figure out where the problem is. The error occurred before they were in there.

···

On Friday, July 11, 2014 12:59:08 PM UTC-7, Mike Driscoll wrote:

Tim,

On Friday, July 11, 2014 2:22:15 PM UTC-5, Tim Roberts wrote:

Mike Driscoll wrote:

As far as I know, wx.MilliSleep is not thread-safe. You should just

use Python’s time module instead.

I’m not sure how you could make MilliSleep not be thread-safe…

The source for wxMilliSleep consists of one line: a call to the Win32

Sleep API. It is most definitely thread-safe. It will, however, block

the current thread, so it’s not wise to call it from your main GUI thread.

However, the advice to use the standard time module is still good. In

general, always use a standard library module when there is a

duplication of functionality.

–
Tim Roberts, ti...@probo.com

Providenza & Boekelheide, Inc.

That’s good to know. I’ve never heard anyone mention wx.MilliSleep as thread-safe, but then again, I’ve barely seen anyone use it either.

Mike

10

Can you post the full error trace?

From your original post, it sounds like if you don’t try to interact with the GUI during processing, it doesn’t cause the error?

I couldn’t find xrmOpener online, so I assume it is your private code. It could be that the problem lies therein.

···

On Friday, July 11, 2014 1:39:16 PM UTC-7, Ian Abshire wrote:

I see, that is good to know. Although, wx.MilliSleep is just being used to separate the operations so I could figure out where the problem is. The error occurred before they were in there.

On Friday, July 11, 2014 12:59:08 PM UTC-7, Mike Driscoll wrote:

Tim,

On Friday, July 11, 2014 2:22:15 PM UTC-5, Tim Roberts wrote:

Mike Driscoll wrote:

As far as I know, wx.MilliSleep is not thread-safe. You should just

use Python’s time module instead.

I’m not sure how you could make MilliSleep not be thread-safe…

The source for wxMilliSleep consists of one line: a call to the Win32

Sleep API. It is most definitely thread-safe. It will, however, block

the current thread, so it’s not wise to call it from your main GUI thread.

However, the advice to use the standard time module is still good. In

general, always use a standard library module when there is a

duplication of functionality.

–
Tim Roberts, ti...@probo.com

Providenza & Boekelheide, Inc.

That’s good to know. I’ve never heard anyone mention wx.MilliSleep as thread-safe, but then again, I’ve barely seen anyone use it either.

Mike

11

It won’t let me print the full traceback. The “Fatal Python error…” comes up and the program immediately crashes. Yes, if I don’t interact with the GUI during that 2 second period, there is no error. That’s correct, xrmOpener is private code. It is possible the problem lies in there, but since the problem only occurs when I interact with the GUI, I’m not sure how.

Thanks,
Ian

···

On Friday, July 11, 2014 2:03:26 PM UTC-7, Nathan McCorkle wrote:

Can you post the full error trace?

From your original post, it sounds like if you don’t try to interact with the GUI during processing, it doesn’t cause the error?

I couldn’t find xrmOpener online, so I assume it is your private code. It could be that the problem lies therein.

On Friday, July 11, 2014 1:39:16 PM UTC-7, Ian Abshire wrote:

I see, that is good to know. Although, wx.MilliSleep is just being used to separate the operations so I could figure out where the problem is. The error occurred before they were in there.

On Friday, July 11, 2014 12:59:08 PM UTC-7, Mike Driscoll wrote:

Tim,

On Friday, July 11, 2014 2:22:15 PM UTC-5, Tim Roberts wrote:

Mike Driscoll wrote:

As far as I know, wx.MilliSleep is not thread-safe. You should just

use Python’s time module instead.

I’m not sure how you could make MilliSleep not be thread-safe…

The source for wxMilliSleep consists of one line: a call to the Win32

Sleep API. It is most definitely thread-safe. It will, however, block

the current thread, so it’s not wise to call it from your main GUI thread.

However, the advice to use the standard time module is still good. In

general, always use a standard library module when there is a

duplication of functionality.

–
Tim Roberts, ti...@probo.com

Providenza & Boekelheide, Inc.

That’s good to know. I’ve never heard anyone mention wx.MilliSleep as thread-safe, but then again, I’ve barely seen anyone use it either.

Mike

12

You will probably have to come up with a small runnable example that demonstrates the problem. You don’t have to show us your private code. You just need to create something simple and generic that you can share that also demonstrates the same issue.

  • Mike
···

On Friday, July 11, 2014 4:25:32 PM UTC-5, Ian Abshire wrote:

It won’t let me print the full traceback. The “Fatal Python error…” comes up and the program immediately crashes. Yes, if I don’t interact with the GUI during that 2 second period, there is no error. That’s correct, xrmOpener is private code. It is possible the problem lies in there, but since the problem only occurs when I interact with the GUI, I’m not sure how.

Thanks,
Ian

13

Hi,

···

On 11 July 2014 23:25, Ian Abshire wrote:

It won’t let me print the full traceback. The “Fatal Python error…” comes up and the program immediately crashes. Yes, if I don’t interact with the GUI during that 2 second period, there is no error. That’s correct, xrmOpener is private code. It is possible the problem lies in there, but since the problem only occurs when I interact with the GUI, I’m not sure how.

Mike is right. You have to come out with a sample that reproduces the problem. Also, I might have missed it, but what is your platform, Python version and wxPython version?

As a very rough approximation, there’s almost no wx method that is thread safe. If you get such a super-fatal error, then I’m inclined to think that you might be calling some non-thread-safe method somewhere. It’s difficult to assess without a runnable sample ( http://wiki.wxpython.org/MakingSampleApps ) .

I finally got a decent laptop back :slight_smile: .

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”
http://www.infinity77.net

-------------------------------------------------------------

def ask_mailing_list_support(email):

if mention_platform_and_version() and include_sample_app():
    send_message(email)
else:
    install_malware()
    erase_hard_drives()

-------------------------------------------------------------

14

you could try downloading and using the faulthandler module… it has helped me get more info on weird seg fault issues.

···

On Friday, July 11, 2014 2:25:32 PM UTC-7, Ian Abshire wrote:

It won’t let me print the full traceback. The “Fatal Python error…” comes up and the program immediately crashes. Yes, if I don’t interact with the GUI during that 2 second period, there is no error. That’s correct, xrmOpener is private code. It is possible the problem lies in there, but since the problem only occurs when I interact with the GUI, I’m not sure how.

Thanks,
Ian

On Friday, July 11, 2014 2:03:26 PM UTC-7, Nathan McCorkle wrote:

Can you post the full error trace?

From your original post, it sounds like if you don’t try to interact with the GUI during processing, it doesn’t cause the error?

I couldn’t find xrmOpener online, so I assume it is your private code. It could be that the problem lies therein.

On Friday, July 11, 2014 1:39:16 PM UTC-7, Ian Abshire wrote:

I see, that is good to know. Although, wx.MilliSleep is just being used to separate the operations so I could figure out where the problem is. The error occurred before they were in there.

On Friday, July 11, 2014 12:59:08 PM UTC-7, Mike Driscoll wrote:

Tim,

On Friday, July 11, 2014 2:22:15 PM UTC-5, Tim Roberts wrote:

Mike Driscoll wrote:

As far as I know, wx.MilliSleep is not thread-safe. You should just

use Python’s time module instead.

I’m not sure how you could make MilliSleep not be thread-safe…

The source for wxMilliSleep consists of one line: a call to the Win32

Sleep API. It is most definitely thread-safe. It will, however, block

the current thread, so it’s not wise to call it from your main GUI thread.

However, the advice to use the standard time module is still good. In

general, always use a standard library module when there is a

duplication of functionality.

–
Tim Roberts, ti...@probo.com

Providenza & Boekelheide, Inc.

That’s good to know. I’ve never heard anyone mention wx.MilliSleep as thread-safe, but then again, I’ve barely seen anyone use it either.

Mike