Opened 13 years ago

Closed 13 years ago

#2489 closed defect (fixed)

Turtleart freezes after 50 minutes

Reported by: tonyforster Owned by: walter
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Turtleart Version: Unspecified
Severity: Unspecified Keywords:
Cc: Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description (last modified by tonyforster)

XO1 373pyg also XO1.5 build 852
Turtleart freezes after 50 minutes, Sugar is still responsive, no error logged, alt tab out and back and the screen is not repainted, stopping from the frame brings up force quit dialog.

If printing time in TA you can log the moment of freezing, in three tries:
started 9h:24m froze 10h:12m
started 22h:20m froze 23h:10m
0:46 froze 1:38

Attachments (4)

Screenshot of _Turtle Blocks Activity_frozen.png (90.7 KB) - added by tonyforster 13 years ago.
Screenshot of _Turtle Blocks Activity_alttab.png (5.1 KB) - added by tonyforster 13 years ago.
Screenshot of _Turtle Blocks Activity_forcequit.png (37.6 KB) - added by tonyforster 13 years ago.
ze logWrite Activity .odt (4.6 KB) - added by tonyforster 13 years ago.
error log

Download all attachments as: .zip

Change History (17)

Changed 13 years ago by tonyforster

Changed 13 years ago by tonyforster

Changed 13 years ago by tonyforster

error log

comment:1 Changed 13 years ago by tonyforster

  • Description modified (diff)

comment:2 Changed 13 years ago by tonyforster

  • Description modified (diff)

comment:3 Changed 13 years ago by walter

I managed to avoid a freeze until after 64 minutes... at first I thought it was a memory leak but it seems to be CPU related. TA is sucking up 100% of the CPU, doing what, I don't know. But it is not consuming an inordinate amount of memory, just 2%.

comment:4 Changed 13 years ago by walter

Running in gdb, it gets stuck in the call to time.clock() in talogo.py, line 299. Not yet sure why.

comment:5 Changed 13 years ago by tonyforster

replaced clock() with localtime().tm_sec and it locks up after round a minute
maybe unrelated reason

does clock wrap back through zero?

comment:6 Changed 13 years ago by tonyforster

changed clock() to time()
still running OK at 1hr25m
OS363au

I suspect overflow (though I cant pick where) there are no tests for overflow that I can see in the code

comment:7 Changed 13 years ago by tonyforster

yes, int(clock()*1000) goes negative at 50 mins
a bit after 2147000
I expect another factor of 1000 headroom
signed int 32 bit=+-2.147 billion?

comment:8 Changed 13 years ago by tonyforster

its clock() that goes -ve, somewhere in Python its a signed int in microseconds

comment:9 Changed 13 years ago by tonyforster

Tried python 2.5 on windows and its still going strong at 3000 seconds
I would call it a python bug
but ta was going to fail every 1000 hrs anyway

comment:10 Changed 13 years ago by walter

There is no reason I can think of to cast the value to an int. I'll try keeping everything float and report back.

comment:11 follow-up: Changed 13 years ago by walter

Hmm. Still froze after 4300 seconds.

comment:12 in reply to: ↑ 11 Changed 13 years ago by tonyforster

Replying to walter:

Hmm. Still froze after 4300 seconds.

was that with clock()? i would expect that
time() cast as int should fail semirandomly in the next 1000 hrs
time() as a float should be ok providing the all code that uses it is also ok

the elegant solution is to replace all code
while t2-t1<x wait
to not wait if t2 < t1
because t2<t1 only if an int has overflowed

comment:13 Changed 13 years ago by walter

  • Resolution set to fixed
  • Status changed from new to closed

http://git.sugarlabs.org/turtleart/mainline/commit/8e82812142c30d07f66a6e39d5b7707af594fd9e

Switching from clock() to time() and int to float seems to have fixed the problem. Still running after almost 6 hours.

Note: See TracTickets for help on using tickets.