Opened 16 years ago
Closed 15 years ago
#302 closed defect (fixed)
Bug: TclThreadManager
| Reported by: | rgrieder | Owned by: | nobody |
|---|---|---|---|
| Priority: | critical | Milestone: | Version 0.2 Codename: Bellatrix |
| Component: | GeneralFramework | Version: | 0.2.0 |
| Keywords: | tcl, thread | Cc: | |
| Referenced By: | References: |
Description
When using threads with the TclThreadManager there has to be a problem somewhere because on dual core systems, it may lead to a runtime error. Try again to find that bug!
Change History (6)
comment:1 Changed 16 years ago by rgrieder
- Summary changed from TclThreadManager bug to Bug: TclThreadManager
comment:2 Changed 15 years ago by scheusso
today i tried to trigger the bug, but i didn't succeed
tclthreadmanager create 1
tclthreadmanager execute 1 for { set x 0 } { $x < 100 } { incr x } { log x }
worked as it should
can anyone remember what triggered this bug ?
comment:3 Changed 15 years ago by scheusso
edit: probably found a way to reproduce it:
tclthreadmanager create 1
tclthreadmanager execute 1 while 1 { addBots 1; killBots 1; }
comment:4 Changed 15 years ago by rgrieder
I couldn't reproduce it though. Even by creating two threads (one creating and one destroying bots). The only thing I noticed was that you couldn't stop the threads with "TclThreadManager destroy 1", but that might be a know issue, I don't know anymore. Btw: It did run on two CPUs, but in debug mode.
comment:5 Changed 15 years ago by rgrieder
Hmm, tried again with a release version. This time (two threads again) I was able to reproduce A bug, but I have no idea whether it is connected to the TclThreadManager. The bug occurred in PlayerInfo while trying to spawn a bots. Apparently the PlayerInfo objects was already destroyed (this pointer was 0xfeeefeee which obviously stands for "free") and still used. Of course I haven't looked into what killBots exactly does. So it might destroy bots while still being use, but just a theory.
comment:6 Changed 15 years ago by landauf
- Resolution set to fixed
- Status changed from new to closed
Fixed in r3307
The reason for the crash was a sloppy synchronisation of the threads. If a thread tried to send a query to ("execute code directly on") the main interpreter, it had to wait until the main interpreter entered a "ready state". But accidently there was no control whether the thread has ended it's query before the main interpreter left the "ready state" or not. Longer queries or parallel processing (on a multicore system) led to undefined behavior and therefore usually to a crash.
Unifying title here.