power off authomatically

reyalp

14111

Re: power off authomatically

« Reply #20 on: 11 / May / 2013, 21:32:00 »

Advertisements

I've looked at this some more.

I'm confident that

Code: [Select]

 3c6afc2:	7878      	ldrb	r0, [r7, #1]

corresponds to

Code: [Select]

                            val = img[y + x + 1]

Furthermore, from the ROMLOG, we see

Code: [Select]

R6  0xB2D6FE98
R7  0xB2D6FE98

In other words, the bogus pointer also appears in R6.
Based on

Code: [Select]

 3c6ae46:	4bc2      	ldr	r3, [pc, #776]	; (3c6b150 <md_detect_motion+0x350>) ; vid_get_viewport_live_fb
 3c6ae48:	f000 fa59 	bl	3c6b2fe <action_stack_AS_MOTION_DETECTOR+0xc2> ; long call
 3c6ae4c:	1e04      	subs	r4, r0, #0
 3c6ae4e:	d103      	bne.n	3c6ae58 <md_detect_motion+0x58>
 3c6ae50:	4bc0      	ldr	r3, [pc, #768]	; (3c6b154 <md_detect_motion+0x354>) ; vid_get_viewport_fb
 3c6ae52:	f000 fa54 	bl	3c6b2fe <action_stack_AS_MOTION_DETECTOR+0xc2> ; long call
 3c6ae56:	1c04      	adds	r4, r0, #0
 3c6ae58:	4bbf      	ldr	r3, [pc, #764]	; (3c6b158 <md_detect_motion+0x358>) ; vid_get_viewport_image_offset
 3c6ae5a:	f000 fa50 	bl	3c6b2fe <action_stack_AS_MOTION_DETECTOR+0xc2> ; long call
 3c6ae5e:	4bbf      	ldr	r3, [pc, #764]	; (3c6b15c <md_detect_motion+0x35c>) ; vid_get_viewport_height
 3c6ae60:	1826      	adds	r6, r4, r0

R6 is vid_get_viewport_live_fb() + vid_get_viewport_image_offset(). The fact that R7 has the same value suggests the crash happened in the first iteration of the loop (in this particular call to md_detect_motion.)

vid_get_viewport_live_fb is exonerated

Code: [Select]

    return viewport_buffers[(active_viewport_buffer-1)&3];

viewport_buffers
ROM:FFB2F90C                 DCD 0x40566B80
ROM:FFB2F910                 DCD 0x405A6000
ROM:FFB2F914                 DCD 0x405E5480
ROM:FFB2F918                 DCD 0x40624900

vid_get_viewport_image_offset is

Code: [Select]

int vid_get_viewport_image_offset() {
	return (vid_get_viewport_yoffset() * vid_get_viewport_byte_width() * vid_get_viewport_yscale()) + (vid_get_viewport_xoffset() * 3);
}

Of these, vid_get_viewport_byte_width and vid_get_viewport_yscale are simple constants.

vid_get_viewport_yoffset and vid_get_viewport_xoffset are both rather nonsensical lookups based on shooting_get_prop(PROPCASE_ASPECT_RATIO)

Code: [Select]

int vid_get_viewport_xoffset() 
{
    // viewport width offset table for each image size
    // 0 = 4:3, 1 = 16:9, 2 = 3:2, 3 = 1:1
    static long vp_w[4] = { 0, 0, 0, 0 };               // should all be even values for edge overlay
    return vp_w[shooting_get_prop(PROPCASE_ASPECT_RATIO)];
}

int vid_get_viewport_yoffset() 
{
    // viewport height offset table for each image size
    // 0 = 4:3, 1 = 16:9, 2 = 3:2, 3 = 1:1
    static long vp_h[4] = { 0, 0, 0, 0 };
    return vp_h[shooting_get_prop(PROPCASE_ASPECT_RATIO)];
}

However, these should be harmless unless the PROPCASE_ASPECT_RATIO value is out of range.

A3400 is defined as a propset 5 cameras, which makes PROPCASE_ASPECT_RATIO 300

This leads to two things that can be tested by someone who has this camera:
1) what is the value of propcase 300 on this camera? In CHDK menu, go to miscellaneous -> debug parameters, set debug data display to props, set Propcase page to 30. Try changing aspect ratios (if available), look at it in REC mode while halfshooting, shooting, and running the MD script.
2) Replace all the nonsense lookups with just a return <value>, or if this camera does in fact have variable aspect ratios that affect the viewport, put in the correct values.

Other possibilities:
1) my analysis above is wrong.
2) There is memory corruption happening somewhere else.

Logged

Don't forget what the H stands for.

reyalp

14111

Re: power off authomatically

« Reply #21 on: 12 / May / 2013, 19:35:02 »

@timgor

Can you tell us what canon settings you are using when you encounter this problem? Image size, shooting mode, things like that?

Logged

Don't forget what the H stands for.

reyalp

14111

Re: power off authomatically

« Reply #22 on: 12 / May / 2013, 20:47:58 »

Looking at the romlog in post 3 http://chdk.setepontos.com/index.php?topic=9804.msg100062#msg100062 I noticed that R6 is a valid viewport address (the 3rd one in the table)

Code: [Select]

R6  0x405E5480
R7  0xD78653C1

Not sure what this means, but if the register usage was similar in the autobuild (likely but not certain), it's not consistent with my idea that vid_get_viewport_image_offset is producing a bad value.

Logged

Don't forget what the H stands for.

timgor

150

Re: power off authomatically

« Reply #23 on: 12 / May / 2013, 23:29:28 »

Hello, thanks for discussing the problem. Right now I am out of my house. I will come back and continue my study after May 20.

Logged

reyalp

14111

Re: power off authomatically

« Reply #24 on: 12 / May / 2013, 23:37:21 »

Quote from: timgor on 12 / May / 2013, 23:29:28

Hello, thanks for discussing the problem. Right now I am out of my house. I will come back and continue my study after May 20.

No problem, thank you for testing.

I've attached a new debug build for when you get back. It should create a files called MD1.DMP and / or MD2.DMP if the problem happens. It should still crash

I've also attached the patch for anyone who is interested.

CHDK-a3400-101a-1.2.0-2772-reyalp-1.zip (350.25 kB - downloaded 23 times.)

md-debug-trunk-2772-reyalp-1.patch (3.55 kB - downloaded 26 times.)

Logged

Don't forget what the H stands for.

timgor

150

Re: power off authomatically

« Reply #25 on: 23 / May / 2013, 11:20:05 »

Hello reyalp!
I just completed a few tests with a following optimistic results:
the compiled application CHDK-a3400-101a-1.2.0-2772-reyalp-1.zip has been working for 40 hours and still working without crash

What did you change there?
you said that "It should create a files called MD1.DMP and / or MD2.DMP"
did you do any changes along with the output files printing?
what subversion number did you use for the compilation?
I want to make tests with and without your change.
Also, I did another test but I think your version needs priority attention now.
Thanks!

« Last Edit: 23 / May / 2013, 11:41:20 by timgor »

Logged

reyalp

14111

Re: power off authomatically

« Reply #26 on: 23 / May / 2013, 13:32:28 »

Quote from: timgor on 23 / May / 2013, 11:20:05

Hello reyalp!
I just completed a few tests with a following optimistic results:
the compiled application CHDK-a3400-101a-1.2.0-2772-reyalp-1.zip has been working for 40 hours and still working without crash

Unfortunately, this isn't good news.

Quote

What did you change there?
you said that "It should create a files called MD1.DMP and / or MD2.DMP"
did you do any changes along with the output files printing?

No, the only change is the debug code. All the changes are in the patch. Basically, it just looks for the "bad" value in the place where I think the crash normally happens, and writes some information to a file. It doesn't change the value so the normal crash should follow immediately afterward.

Quote

what subversion number did you use for the compilation?

2772

Logged

Don't forget what the H stands for.

timgor

150

Re: power off authomatically

« Reply #27 on: 23 / May / 2013, 13:40:59 »

Anyway, I will try to compile this version on my computer and investigate it. Something definitely has been changed and we have a chance to know what.

« Last Edit: 23 / May / 2013, 13:42:49 by timgor »

Logged

reyalp

14111

Re: power off authomatically

« Reply #28 on: 23 / May / 2013, 15:52:49 »

Quote from: timgor on 23 / May / 2013, 13:40:59

Anyway, I will try to compile this version on my computer and investigate it. Something definitely has been changed and we have a chance to know what.

Although I don't see a mechanism, it may be possible that the problem fixed in http://trac.assembla.com/chdk/changeset/2762/ was related. I think all of our previous test builds were before that.

If you want to test this theory, try trunk builds of 2761 and 2762.

It's also possible that the optimization change just hides the actual bug somehow...

Logged

Don't forget what the H stands for.

timgor

150

Re: power off authomatically

« Reply #29 on: 23 / May / 2013, 16:13:48 »

I have compiled 2761, 2762 and 2772. I will run it tonight and see what will be.
Next, I am going to replace actual md_detect_motion(void) function for failing revision by fake one that returns "detected motion" every 5 minutes.

Code: [Select]

static int md_detect_motion(void)
{
    
   int idx, tick, rv;
   int val, cy, cv, cu;

    register int col, row, x, y;

    if(!md_running())
    {
        return 0;
    }

    tick = get_tick_count();
    rv = 1;
#ifdef OPT_MD_DEBUG
    if(motion_detector.comp_calls_cnt < MD_REC_CALLS_CNT)
    {
        motion_detector.comp_calls[motion_detector.comp_calls_cnt]=tick;
    }
    motion_detector.comp_calls_cnt++;
#endif

    if(motion_detector.start_time + motion_detector.timeout < tick )
    {
        md_save_calls_history();
        motion_detector.running = 0;
        motion_detector.return_value = 1;
        return 0;
    }
    
    
    if(motion_detector.last_measure_time + motion_detector.measure_interval > tick)
    {
        // wait for the next time
        return 1;
    }

    motion_detector.last_measure_time = tick;

    
    return 1;
}

Logged