Bug Reports against Recent Builds -- Report bugs here - page 22 - CHDK Releases - CHDK Forum supplierdeeply

Bug Reports against Recent Builds -- Report bugs here

  • 281 Replies
  • 100843 Views
*

Offline srsa_4c

  • ******
  • 4426
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #210 on: 24 / January / 2013, 17:15:35 »
Advertisements
Same crash happens on the current CHDK 1.1 autobuild release (Ixus40), but the only way to trigger it is trying to change the "value factor" from "off" after
extra photo operations -> override subj. dist. value
(still talking about play mode).

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #211 on: 24 / January / 2013, 17:24:36 »
Can you upload the ROMLOG and corresponding main.dump file for the build that caused the crash please.
Sure, however note that the romlog is quite different and I found no way to get it out into a file yet. It's located at the start of the ROM dump (starts at 0xff800000).
Also attached is the source diff and the main.dump (see updated previous post).

update:
ixus40, CHDK trunk: same issue
ixus65: no problem

ixus30:
- forced rec_mode_active() to return 0, issue remains

Any way to extract the stack trace from the ROM?

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline srsa_4c

  • ******
  • 4426
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #212 on: 24 / January / 2013, 17:35:10 »
Any way to extract the stack trace from the ROM?
Not with the default assert handler. I'll try to replace it.
The investigation would probably be easier if the user with the most recent S5IS report would post the romlog  :(

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #213 on: 24 / January / 2013, 17:38:58 »
Any way to extract the stack trace from the ROM?
Not with the default assert handler. I'll try to replace it.
The investigation would probably be easier if the user with the most recent S5IS report would post the romlog  :(

Really need the main.dump as well that matches the build - without this it's very hard to trace where in CHDK it was executing when it crashed.

Can you get a ROMLOG from the Ixus40?

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


*

Offline srsa_4c

  • ******
  • 4426
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #214 on: 24 / January / 2013, 17:54:30 »
Really need the main.dump as well that matches the build - without this it's very hard to trace where in CHDK it was executing when it crashed.

Can you get a ROMLOG from the Ixus40?
There are logging functions in the firmware, but they don't work the way as in later cameras. The "log", as I mentioned earlier, is written to the start of the flash ROM. But it doesn't seem to include a stacktrace.
I'll try using a custom assert routine and report back.

*

Offline srsa_4c

  • ******
  • 4426
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #215 on: 24 / January / 2013, 18:59:05 »
I'll try using a custom assert routine and report back.
I have reused my lame custom assert routines from the S1 port, the result is not too user friendly, you'll need a hex viewer.
structure of asrt0001.dmp:
timestamp, r0, r1, r2 (debugassert's arguments) as text
**STACK**STACK** as text
256 bytes stack dump, binary
*RAMDMP 0x1000-* as text
0xa0000 bytes RAM dump from 0x1000, binary
Also included main.bin.dump, a text file with the task name, and the port's diff with the debug routines. Based on trunk code.


backtrace:
lens_get_focus_pos ->
shooting_get_lens_to_focal_plane_width ->
shooting_get_subject_distance_override_value ->
gui_subj_dist_override_value_enum ->
gui_menu_draw_state_value


the port's wrappers.c will need a fix, I guess....

fix committed for ixus40_sd300 in https://trac.assembla.com/chdk/changeset/2516
« Last Edit: 26 / January / 2013, 10:43:20 by srsa_4c »

Re: Bug Reports against Recent Builds -- script parameter defaults
« Reply #216 on: 31 / January / 2013, 20:07:55 »
There have been several recent discussions about the workings of saved script parameter sets.  I think I've narrowed down one of the bugs ( rev 2529 - trunk 1.2.0 )

I currently have the Save params [ ] menu item disabled.  It had previous been enabled and thus there are saved parameters files for some script names.

When I start the camera, switch into <ALT> mode, and immediately start the current script,  the  script parameters are set to the value specified by the script's @default value.   However, if I then go into the Script menu and reload the script from the file browser,  those same parameters are then set to the value stored in the saved parameter file.   

Even though Save params [  ] is disabled.

At first it seems to that with Save params[ ] disabled,  scripts should only use the @default value specified in the script itself?  Regardless of whether there are configuration parameters stored for that script on the SD card ?   Or should it use the saved parameter values if they exist regardless of the state of  Save params [  ] ?

Update : I deleted all the stored script parameter files and tried to recreate the situation described above. I turned on Save params [  ], set some non-default parameter values,  and then turned it back off.   I no longer get a different set of parameter values on startup vs script reload - I now always get what's in the stored parameter file (again regardless of the state of the Save params [  ] setting.

Deja vu - we are back to the discussion about having seperate Save Param and Load Param menu options I guess.
« Last Edit: 31 / January / 2013, 20:21:31 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #217 on: 31 / January / 2013, 20:29:05 »
Update : I deleted all the stored script parameter files and tried to recreate the situation described above. I turned on Save params [  ], set some non-default parameter values,  and then turned it back off.   I no longer get a different set of parameter values on startup vs script reload - I now always get what's in the stored parameter file (again regardless of the state of the Save params [  ] setting.

You didn't save them by any chance so I can look at the content?

Quote
Deja vu - we are back to the discussion about having seperate Save Param and Load Param menu options I guess.

Another solution would  be to add a new option to the menu item that selects the parameter set to use. Currently the allowed values are 0 - 9; but it would be possible to add 'Default' as an option which would bypass loading any param file.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #218 on: 31 / January / 2013, 20:39:44 »
You didn't save them by any chance so I can look at the content?
I certainly did.   I even looked at it myself (after posting above) and sure enough the first line is slightly corrupted.

Code: [Select]
@param a Columnslay (sec)
@default a 8
@param b Rows
@default b 8
@param d Timeout
@default d 60500
@param f Trigger Threshold
@default f 900

So I cleaned that up and tested again.  This time the saved params are loaded at startup and the @default parameter get loaded when the script is reloaded from the file browser.

Code: [Select]
@param a Columns
@default a 8
@param b Rows
@default b 8
@param d Timeout
@default d 60500
@param f Trigger Threshold
@default f 900

Do you want the actual files ?

Quote
Another solution would  be to add a new option to the menu item that selects the parameter set to use. Currently the allowed values are 0 - 9; but it would be possible to add 'Default' as an option which would bypass loading any param file.
Now there is a good idea!
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: Bug Reports against Recent Builds -- Report bugs here
« Reply #219 on: 31 / January / 2013, 20:49:30 »
You didn't save them by any chance so I can look at the content?
I certainly did.   I even looked at it myself (after posting above) and sure enough the first line is slightly corrupted.

Code: [Select]
@param a Columnslay (sec)

I think the file corruption was caused by the bug I fixed in 2527 - so it shouldn't happen again (fingers crossed).

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics