navi homePPSaboutscreenshotsdownloaddevelopmentforum

Opened 12 years ago

Closed 12 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:


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 12 years ago by rgrieder

  • Summary changed from TclThreadManager bug to Bug: TclThreadManager

Unifying title here.

comment:2 Changed 12 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 12 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 12 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 12 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 12 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.

Note: See TracTickets for help on using tickets.