Runtime Error: Thread is detached but not suspended

Why am i not allowed anymore to EDIT my POSTS? :frowning:

<https://xojo.com/issue/34519>

I found 1 of my Threads still running while my App called Quit.
This 1 Thread was querying a mySQL Database in our local Network (TCP/IP).

Since i made sure ALL Threads ended or have been killed before the App calls Quit, the error seems to be gone (i hope).

Updated my Feedback Case.

[quote=112999:@Sascha S]The App is connected to 7 mySQL and 1 MS SQL Databases and only 2 Threads using Database connections.
I am always using the latest Xojo release.[/quote]
Was just wondering because you’d said

[quote=104943:@Sascha S]A Desktop Application on Windows 7. Written with X2014 R1.1 on OS X Mavericks.

[/quote]

Yes, because back then this was the latest release :wink:

I am now hunting this error for more than 1 Year :slight_smile:

I am still seeing this error when i make heavy use of Threads which access mySQL Databases:

An example:
I have a Window with 3 Listboxes, 2 TextAreas and 1 PopupMenu. When the user selects an entry from the 1st Listbox a Thread is started which just makes a SQL query and stores the RecordSet in a private property of the window. A Timer is waiting for the Thread to finish and is then presenting the RecordSet data in the 2nd Listbox. Then in the change event of ListBox 2 the same Thread is called, making another query while another Timer waits for the Thread to end (If Thread.Sate = Thread.NotRunning…). The third ListBox change event fires the Thread again with another query and a Timer again waits for the ending of the Thread to display Data from the RecordSet in the TextAreas and populates the PopupMenu.

If the user is clicking in a ListBox the Thread shall be started with a new query. I am trying to prevent killing the Thread, because i’ve read that killing Threads is “not good”. Because of this, i have (If Thread.State <> Thread.NotRunning Then Return True) in the MouseDown and KeyDown Events of the Listboxes. This sometimes results in a “no response” situation on clicks and keypresses, but this is ok because the Thread is finishing really fast in most cases. And i would be fine with short “lags” and those “no response” situations, if the program would be stable.

On windows, often when i click “too fast” within the Listboxes or while i am navigating “too fast” with the Keyboard within my Window, i see the above error.
On OS X i have seen this issue only 2-3 times within the last year.
If i set the Period time of the Timers to 100+ ms the error is less often to see. If i go below 100ms the error occurs very often. But with a 100+ms Period, i have more “no response” situations.

BTW: These crashes can’t be catched within the debugger. Xojo is crashing too then.

The error you are seeing sounds like it is caused by a thread in a “weird” state. I wonder if you’d have better luck of creating new thread objects an only using each one once. Don’t try to use the same thread twice, in other words?

Although you can put a thread object as a control on a window, you can also just define a thread subclass, and then you can simply New as many as you want when you need a new one.

Are a Subclass in a Module and an Object dragged into the Editor 2 different things?
May i should create a Subclass and work with a Thread Array?

The question is, how many instances do you have?

Personally, I would probably do this:

  Class cMyThread   // a thread subclass

  Window1
   // an array holding my thread subclasses
   property myThreads() as cMyThread


// when doing a new search
  Window1
   Method NewSearch(search as string)
   dim t as new cMyThread
   t.search = search
   myThreads.append(t) // remember this instance
  t.Run

Or something like that.

Hello @Michael Diehr

I thought about doing it like you say, but i am fearing a bit that i would open a gate to some kind of memory leak. If old Threads in this array do not end, will they continue to live until i have so many Threads that i run out of memory at some point? And if i would kill “very old” Threads, would i trigger the same crashes again?

Yes, it would leak as is, but one could have the threads clean up after themselves pretty easily:

   Class cMyThread // a thread subclass
        cMyThread.Run
                 for i = 1 to 100
                           // do the task
                 next
              // all done, clean up
                Window1.myThreads.remove(window1.mythreads.indexOf(me))

A more sophisticated way would be to use a Class with Shared Methods and Shared Properties to do this, but it sounds like your main goal is simply figuring out why the Assertion is triggered and avoiding it if possible.