Canvas and surfaceView example crash/freeze - Memory Leak?

http://www.helloandroid.com/tutorials/how-use-canvas-your-android-apps-part-1

At the end of this tutorial link for source code download is available. I downloaded the code and tried this example , It draws a kangaroo in the screen and within 1-2 minutes i get a crash/the application froze.

I tried on Archos 70 Internet Tablet.

"I would like to know the reason, or if some thing is wrong in this "

Here is the LogCat

04-13 17:03:24.089: DEBUG/ondraw(2070): lefutott

04-13 17:03:24.097: DEBUG/ondraw(2070): lefutott

04-13 17:03:24.113: DEBUG/ondraw(2070): lefutott

04-13 17:03:24.128: DEBUG/ondraw(2070): lefutott

04-13 17:03:24.136: DEBUG/ondraw(2070): lefutott

04-13 17:03:24.152: DEBUG/ondraw(2070): lefutott

04-13 17:03:24.167: DEBUG/ondraw(2070): lefutott

04-13 17:03:24.175: DEBUG/ondraw(2070): lefutott

04-13 17:04:10.019: WARN/ActivityManager(1302): Timeout of broadcast BroadcastRecord{457f99c8 android.intent.action.TIME_TICK} - receiver=android.app.ActivityThread$PackageInfo$ReceiverDispatcher$InnerReceiver@4561a5c8

04-13 17:04:10.019: WARN/ActivityManager(1302): Receiver during timeout: BroadcastFilter{454ed4c8 ReceiverList{454fbd70 1302 sy开发者_运维百科stem/1000 local:4561a5c8}}

04-13 17:04:38.972: INFO/Process(1302): Sending signal. PID: 1302 SIG: 3

04-13 17:04:38.972: INFO/dalvikvm(1302): threadid=3: reacting to signal 3

04-13 17:04:39.097: INFO/dalvikvm(1302): Wrote stack traces to '/data/anr/traces.txt'

04-13 17:05:09.097: INFO/Process(1302): Sending signal. PID: 1302 SIG: 3

04-13 17:05:09.097: INFO/dalvikvm(1302): threadid=3: reacting to signal 3

04-13 17:05:09.128: INFO/dalvikvm(1302): Wrote stack traces to '/data/anr/traces.txt'

04-13 17:05:09.128: INFO/Process(1302): Sending signal. PID: 1433 SIG: 3

04-13 17:05:09.128: INFO/dalvikvm(1433): threadid=3: reacting to signal 3

04-13 17:05:09.144: INFO/dalvikvm(1433): Wrote stack traces to '/data/anr/traces.txt'

04-13 17:05:11.144: INFO/Watchdog_N(1302): dumpKernelStacks

04-13 17:05:11.144: ERROR/Watchdog_N(1302): Unable to open stack of tid 1302 : 13 (Permission denied)

04-13 17:05:11.144: ERROR/Watchdog_N(1302): Unable to open stack of tid 1303 : 13 (Permission denied)

The onDraw looks like this:

    @Override
    public void onDraw(Canvas canvas) {

            Paint paint = new Paint();


            Bitmap kangoo = BitmapFactory.decodeResource(getResources(),
                            R.drawable.kangoo);
            canvas.drawColor(Color.BLACK);
            canvas.drawBitmap(kangoo, 10, 10, null);
    }

So each time it runs, it's creating a new paint and possibly (I've not used the BitmapFactory), creating a new bitmap. This seems like overkill (particularly, since the paint isn't used, although it does seem to be in part 2). I'd consider moving these bits to the constructor for the panel to see if it makes a difference, something like:

public class Panel extends SurfaceView implements SurfaceHolder.Callback{
    // rest of class ignored for brevity

    private Paint paint;
    private Bitmap kangoo;

    public Panel(Context context, AttributeSet attrs) {
    super(context, attrs); 
    getHolder().addCallback(this);
    canvasthread = new CanvasThread(getHolder(), this);
    setFocusable(true);
         paint = new Paint();


         kangoo = BitmapFactory.decodeResource(getResources(),
                            R.drawable.kangoo);
}

    @Override
    public void onDraw(Canvas canvas) {                
            canvas.drawColor(Color.BLACK);
            canvas.drawBitmap(kangoo, 10, 10, null);
    }
}

It may also be worth running it in the emulator to see if you get the same problem, or if it is device specific.

EDIT: It's also worth noting that the run() method in the CanvasThread class doesn't have any sleeps in it, so it's running as fast as it can, redrawing the screen. This is probably ok for a tutorial, but in a real app I would expect some kind of target frame rate with an appropriate sleep in the run method, otherwise it seems like you would be using an awful lot of cpu cycles (and presumably battery) that the user probably isn't going to notice.