Bug Reports against Recent Builds -- Report bugs here - page 3 - CHDK Releases - CHDK Forum  
« previous next »
Pages: 1 2 [3] 4 5 6 7 8 ... 29   Go Down

Bug Reports against Recent Builds -- Report bugs here

  • 281 Replies
  • 133408 Views
*

Offline reyalp

  • ******
  • 14110
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #20 on: 12 / August / 2008, 15:43:58 »
Advertisements
Quote from: fudgey on 12 / August / 2008, 06:45:44
My first thought is that it's intermittent (also) because flash charging time varies, and that the problem is that CHDK stays in a loop waiting for the flash without letting the camera's software work it's magic, including watchdog resets.
Interestingly, I'm don't need to actually use the flash for this to happen, or even trigger the pre-flash / af assist beam. It does seem like it might depend on subject and/or lighting but I haven't worked out exactly how.

Putting a simple timeout in the loop (get tick count, bail out after 1 second) avoids the shutdown.

Quote
I don't know how often the camera resets its watchdog, so the phase of the reset period could also be a source of variation.
Good point. It would be interesting to know when and how the camera watch dog triggers. It's also be nice to make a BSOD sort of thing instead of shutting down :)
Logged
Don't forget what the H stands for.
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #21 on: 13 / August / 2008, 03:25:33 »
It's an age-old bug. The condition occurs if you (i) set flash to Auto, (ii) set some exposure parameter override, and (iii) shoot in bright light, so that the flash is not used. Then the following function

int shooting_is_flash_ready()
{
   int t = 0;
   _GetPropertyCase(PROPCASE_FLASH_MODE, &t, sizeof(&t));
   if ((t != 2) && (shooting_in_progress()))
    return (shooting_is_flash() && _IsStrobeChargeCompleted());
   return 1;
}

returns 0, so that the loop

    while ((shooting_is_flash_ready()!=1) || (focus_busy));

becomes infinite and hangs CaptSeqTask. Then, after 10s or so, the watchdog kicks in.

Correcting, instead of
   if ((t != 2) && (shooting_in_progress()))
    return (shooting_is_flash() && _IsStrobeChargeCompleted());
one should say
   if ((t != 2) && (shooting_in_progress()))
     if (shooting_is_flash()) return _IsStrobeChargeCompleted();

Logged
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #22 on: 13 / August / 2008, 04:32:02 »
hm, so this behaviour should occur on all cameras, right?
will do some tests tonight.
this fix of yours, is it considered to be safe and not breaking anything? if yes (perhaps some people can do tests) i can patch the trunk and the branch. right?
Logged
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #23 on: 13 / August / 2008, 05:34:44 »
Quote from: PhyrePhoX on 13 / August / 2008, 04:32:02
hm, so this behaviour should occur on all cameras, right?

I should believe so. I'm surprised nobody except reyalp complained yet. Scared perhaps...

Quote
will do some tests tonight.
this fix of yours, is it considered to be safe and not breaking anything? if yes (perhaps some people can do tests) i can patch the trunk and the branch. right?

In my understanding it's a safety fix, not break. Testing never hurts though...

Logged
*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #24 on: 13 / August / 2008, 06:34:43 »
Suggestion to eliminate unnecessary compiler warnings (juciphox 479, all cams):

Quote
ubasic.c: In function `case_statement':
ubasic.c:830: warning: 'gosub_ln' might be used uninitialized in this function
ubasic.c: In function `case_else_statement':
ubasic.c:919: warning: 'gosub_ln' might be used uninitialized in this function
kbd.c: In function `kbd_process':
kbd.c:565: warning: 'drmode' might be used uninitialized in this function

these 3 are all no-brainers: all 3 are in the initial declarations after the
function headers, so gcc will initialise them to 0 anyway, won't it ?
just add '= 0' and presto

Quote
lmathlib.c: In function `math_pow':
lmathlib.c:118: warning: implicit declaration of function `luai_ipow'

'lmathlib.c' needs to declare `luai_ipow' an external function,
because it is defined in 'lvm.c'
I tried, but couldn't get it done, all his recursive macroing in the LUA
sources kinda baffles me - the price of portability, i guess ...
should be easy for some of you, though  :D

IMHO with these changes all cams that have 0 errors/warning in trunk would do
so in juciphox as well

wim
« Last Edit: 13 / August / 2008, 06:39:53 by whim »
Logged
*

Offline reyalp

  • ******
  • 14110
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #25 on: 13 / August / 2008, 15:37:10 »
Quote from: whoever on 13 / August / 2008, 03:25:33

Correcting, instead of
   if ((t != 2) && (shooting_in_progress()))
    return (shooting_is_flash() && _IsStrobeChargeCompleted());
one should say
   if ((t != 2) && (shooting_in_progress()))
     if (shooting_is_flash()) return _IsStrobeChargeCompleted();


Oh that makes sense. I'm embarrassed to say I looked at that a couple times and didn't notice
Logged
Don't forget what the H stands for.
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #26 on: 13 / August / 2008, 15:59:42 »
Quote from: reyalp on 13 / August / 2008, 15:37:10
Oh that makes sense. I'm embarrassed to say I looked at that a couple times and didn't notice

In which case would somebody rectify, please. And while at it, perhaps also remove the few unhelpful lines in that same function.

Logged
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #27 on: 13 / August / 2008, 16:38:23 »
Well, one more little fix for the trunk. A brief click on the "Alt" button is supposed to invoke/dismiss the alt-menu. Well, invoke it does, but on the way out "Alt" remains clicked, so if there's a regular function on that button, it gets invoked whenever exiting the alt-menu. A simple fix takes just a few lines in core/kbd.c, namely instead of

   if ((key_pressed == 2) && !kbd_is_key_pressed(conf.alt_mode_button)){
       key_pressed = 0;
   }

say

   if (key_pressed == 2) {
     if (kbd_is_key_pressed(conf.alt_mode_button))
       return 1;   // wait until Alt released before unblocking kbd
     else
       key_pressed = 0;
   }

Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #28 on: 13 / August / 2008, 17:00:11 »
Quote from: whoever on 13 / August / 2008, 16:38:23
Well, one more little fix for the trunk. A brief click on the "Alt" button is supposed to invoke/dismiss the alt-menu. Well, invoke it does, but on the way out "Alt" remains clicked, so if there's a regular function on that button, it gets invoked whenever exiting the alt-menu. A simple fix takes just a few lines in core/kbd.c, namely instead of

Sounds like fix #7 in My modifications to CHDK, already in juciphox since #417. I use a (bit old by now) trunk build with some patches including ljl's zebra and cyril42e's alt fix and both work well. Your modification is suspiciously lot simpler, though...
Logged
*

Offline whoever

  • ****
  • 280
  • IXUS950
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #29 on: 13 / August / 2008, 17:08:32 »
Quote from: fudgey on 13 / August / 2008, 17:00:11
Sounds like fix #7 in My modifications to CHDK, already in juciphox since #417. I use a (bit old by now) trunk build with some patches including ljl's zebra and cyril42e's alt fix and both work well. Your modification is suspiciously lot simpler, though...

Could be. I was talking about the trunk not branches though. I hope it will remain the source reference, while branches will remain such.

Logged
Pages: 1 2 [3] 4 5 6 7 8 ... 29   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal