help: how to debug script interrupting? - page 5 - General Discussion and Assistance - CHDK Forum

help: how to debug script interrupting?

  • 224 Replies
  • 64764 Views
Re: help: how to debug script interrupting?
« Reply #40 on: 08 / July / 2012, 07:54:44 »
Advertisements
in the meanwhile here are other screenshots of error (dev build 1950, not yet used the one provided above)

script used:
Code: [Select]
--[[
@title NEORtest2
]]
   
while true do
    sleep(1000)
end



error screenshot:

(happened about 15 min after starting, but, as said, this is random, sometimes is happens after few min, sometimes after 1 hour...)

Re: help: how to debug script interrupting?
« Reply #41 on: 08 / July / 2012, 08:06:52 »
Quote
These are trunk builds so you will need the modules along with the DISKBOOT.BIN/PS.FI2

I was trying to install them on my cam. If I use the DISKBOOT.BIN provided by you in the no-exmem version the cam doesn't turn on at all... So I used DISKBOOT.BIN from exmem version in both, this should not cause problems, right...?

thanks
« Last Edit: 08 / July / 2012, 08:56:53 by Alarik »

Re: help: how to debug script interrupting?
« Reply #42 on: 08 / July / 2012, 09:45:04 »
Ok, so even on my private cam I reproduced the error using the private version you provided me,
so:

- EXMEM Version  ( CHDK-sx130is-101f-1.1.0.1956-reyalp-exmem-1.zip )

(the no-exmem is still running...)

got my usual error but this time, thanks to you, had a DUMP (LUAERR.DMP)

here's a link to it: http://www.experience-3.com/LUAERR.DMP

or please give me some hints on how analyze that file

thanks
« Last Edit: 08 / July / 2012, 09:53:03 by Alarik »

Re: help: how to debug script interrupting?
« Reply #43 on: 08 / July / 2012, 09:59:12 »
error also on the no-exmem version
this time had something written on the display:

NULL err ?!
PRESS SHUTTER TO CLOSE

even this time I had the dump, here's the link:
http://www.experience-3.com/LUAERR2.DMP

thanks for any advice



Re: help: how to debug script interrupting?
« Reply #44 on: 08 / July / 2012, 10:02:49 »
forgot:
Quote
If it boots, please report the values in "miscellaneous->show memory info"

these are the values shown:
Free memoty: 1827032 bytes
CHDK size: 226160 bytes
loaded at: 0x3B089E0

Re: help: how to debug script interrupting?
« Reply #45 on: 08 / July / 2012, 10:15:49 »
If I use the DISKBOOT.BIN provided by you in the no-exmem version the cam doesn't turn on at all
Assuming you installed correctly,  this most likely means that even a stripped version of CHDK will not run at all on the sx130 without the use of extended memory enabled.  (reyalp could delete Lua too but what would you do with it ?).

Quote
... So I used DISKBOOT.BIN from exmem version in both, this should not cause problems, right...?
The only difference between the two versions he built for you is the actual DISKBOOT.BIN file  ( and the file used for firmware update - PS.FI2).   So by copying the DISKBOOT.BIN to the other version, you have essentially made them identical.  Not a problem - just an unnecessary step :)
« Last Edit: 08 / July / 2012, 10:17:27 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14126
Re: help: how to debug script interrupting?
« Reply #46 on: 08 / July / 2012, 14:57:00 »
Quote
These are trunk builds so you will need the modules along with the DISKBOOT.BIN/PS.FI2

I was trying to install them on my cam. If I use the DISKBOOT.BIN provided by you in the no-exmem version the cam doesn't turn on at all... So I used DISKBOOT.BIN from exmem version in both, this should not cause problems, right...?
The diskboot.bin is the core of CHDK, so if you use the exmem diskboot, you are running the exmem version.

The fact that the no-exmem one doesn't load means there isn't enough memory (or possibly something else, there is some weirdness in the non-exmem startup for this camera...)
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14126
Re: help: how to debug script interrupting?
« Reply #47 on: 08 / July / 2012, 14:59:54 »
error also on the no-exmem version
Since you are using the diskboot from the exmem version, this is the exmem version.
Quote
this time had something written on the display:
NULL err ?!
PRESS SHUTTER TO CLOSE
Ok, this means that where there was supposed to be an error message, there was null instead.

I'll take a look at the dumps you provided.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14126
Re: help: how to debug script interrupting?
« Reply #48 on: 08 / July / 2012, 17:20:38 »
OK, here's my quick and dirty chdkptp script to parse the dumps, plus results from from the dump in post #42. Note that the stuff at the end of the stack dump (following the long run of 0x19980218) probably belongs to some other task, not relevant here. There are a few other deficiencies in the dump and test build setup as well.

analysis to follow...

edit:
annotated stack trace with function names

edit:
The dump from post 43 is essentially identical.

The exmem info shows there is plenty of free memory in the CHDK heap.

The stack trace shows that there is plenty of stack available (mykbd_task is only at sp+124)

The stack doesn't appear to be trashed, although it could have been in the code we long jumped out of.

Both encounter a lua error in lua_script_run. Since lua error does a longjump, there's no obvious indication of where the original error happened.

I don't think more dumps with this code are likely to provide much value, but the decode process is simple so if you have them feel free to post. Don't go out of your way to collect more though.

Further directions:
Try to do the dump in lua code before the longjump
Try to detect memory corruption in exmem
Other ideas ?
« Last Edit: 08 / July / 2012, 17:41:52 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14126
Re: help: how to debug script interrupting?
« Reply #49 on: 09 / July / 2012, 02:30:39 »
Here's two new builds with some different debug code. The dump is now taken whenever lua throws an error, before the longjump. The dump file will always be named LUAERR.DMP

The non-exemem build excludes lua io, os and string libraries. This will make it quite useless for real scripts, but it should run the "NEORtest2" test script. It also uses the odd MEMISOSTART value found in SVN...

If this non-exmem build fails to boot, don't bother messing with it further, just run the exmem version. If the non-exmem does boot, report the free memory as before.

The dump format has changed, and can no longer be decoded by the script attached above. It can now be loaded decoded using the code in chdkptp/lua/extras/dbgdump.lua
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal