help: how to debug script interrupting? - page 10 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 23   Go Down

help: how to debug script interrupting?

  • 224 Replies
  • 64719 Views
*

Offline outslider

  • *****
  • 762
Re: help: how to debug script interrupting?
« Reply #90 on: 15 / September / 2012, 06:38:25 »
Advertisements
Oh, I missed this thread before. I own sx130 and had this error a few times during using intervalometers. I used especially my intervalometer with auto exposure:

http://chdk.setepontos.com/index.php?topic=7757.0

Since the script is a little complicated I thought there might be some bug in the code. Now I believe there could the same reason as in your case.

What cause me thinking is the code reason - I had the problem a few times at moreless the same time - around 4 am when the script was running to sunrise. I thought that some number in brightness calculation becomes 0 or something and some error like 'division by zero' causes problem. But there were script fails also in other conditions.

In summary - I can confirm, that my sx130 had this bug some time ago. I didn't run intervalometer for few months, but I'll try to test the cam with the lastest Alarik code:

Code: [Select]
--[[
@title NEORtest2
]]

while true do
    sleep(100)
end

PS. pretty nice script, what is the license ;)?
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline Alarik

  • **
  • 83
Re: help: how to debug script interrupting?
« Reply #91 on: 16 / November / 2012, 11:29:16 »
Hi all,
any news about this bug from anyone?

tks
Logged
*

Offline lapser

  • *****
  • 1093
Re: help: how to debug script interrupting?
« Reply #92 on: 16 / November / 2012, 22:15:05 »
Quote from: Alarik on 16 / November / 2012, 11:29:16
Hi all,
any news about this bug from anyone?
tks
I just got finished reading the entire topic. Whew! It sounds possible that it's a hardware problem, even though the rule is: "It's always software, never hardware."

Have you ever had the problem with a camera running on a battery? From my recording studio days, when you hook a lot of electronic devices up to A/C power, you create "ground loops". If there's a transformer inside a loop, it will generate a current in the loop, which shows up as hum in audio. In a digital circuit, a strong enough "hum" might flip a bit. Have you tried it with a single camera running on a battery far away from everything else electrical?

To avoid ground loops, all the cameras should be powered by a single DC supply, and the ground wires from all the cameras should be connected to a single point. The unshielded power wires may cause problems too, from RFI. You could try using balanced microphone cable, with the shield connected to ground at the power supply only.

I suspect that the most sensitive circuit to interference would be the memory card. Resistance in the connection would aggravate the problem, as would cheap and higher capacity card design. I'm not sure how the lua/ubasic interpreters work, but if they fetch instructions from the memory card each time, a glitch would corrupt the instruction and create this kind of error.

A good test would be to add a continuous memory test of the external card from CHDK without Lua running. You could also try different cards, i.e. higher quality and/or lower capacity, and see if that solves the problem.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline Alarik

  • **
  • 83
Re: help: how to debug script interrupting?
« Reply #93 on: 17 / November / 2012, 08:40:33 »
thankyou very much for your complete answer.
Actually at the beginning I though that the problem could be due to a power problem, but then I experienced the problem even with just one cam, moreover the fact that the same problem has been encountered by other sx130is cameras (and only those one) made me think that the problem is the cam itself (but dont know why...).
If I remove the sdcard after the script has been loaded, it still works so I dont think that the cam fetches instructions from the memory card each time... so I would exclude the sdcard as the cause of  the problem.

However I'll try to let them run with just batteries to the doublecheck the "powersupply" problem.
I'll post the results.
Thanks.
Logged
*

Offline lapser

  • *****
  • 1093
Re: help: how to debug script interrupting?
« Reply #94 on: 17 / November / 2012, 17:07:27 »
Quote from: Alarik on 17 / November / 2012, 08:40:33
If I remove the sdcard after the script has been loaded, it still works so I dont think that the cam fetches instructions from the memory card each time... so I would exclude the sdcard as the cause of  the problem.
You mean you remove the SD card with the power on? On my cameras, opening the door to get to the card cuts the power. And the Lua interpreter might be loading chunks of code as it needs them, if the whole script doesn't fit into memory.

I just encountered a strange Lua load bug that may or may not be related to this problem.

I've been working on a long Lua program, repeatedly making small changes and saving the new Lua file on the SD (32G) card. I added some print() statements, and when I saved the new file on the card, they didn't print! After much experimenting, I found that I could get them to print by reloading the same Lua script file. I can't reproduce it with smaller files.

It must be running the old Lua file, even though it's no longer on the card, since the script ran but without the changes. This is with turning the camera off, taking out the card, saving the new file on the card (over the old one), and restarting CHDK, then running the script.

Unless the Lua script is persisting in camera memory, this means that it's loading the old, deleted file and running it. Eventually, that part of the card would be re-used, and crash the script.

Easy way to test if this is your bug would be to re-load the script manually after powering on.

Anyone familiar with the Lua loader that might be able to explain this? Thanks.

CHDK 1.2.0-2267
sx260hs 100b
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline reyalp

  • ******
  • 14126
Re: help: how to debug script interrupting?
« Reply #95 on: 17 / November / 2012, 17:33:00 »
Quote from: lapser on 17 / November / 2012, 17:07:27
You mean you remove the SD card with the power on? On my cameras, opening the door to get to the card cuts the power. And the Lua interpreter might be loading chunks of code as it needs them, if the whole script doesn't fit into memory.
When a script is selected from the menu, the entire script source is loaded into memory (script.c script_load). When run, it is compiled by the lua interpreter from the source in memory. The only time script code will be loaded from SD card at runtime is if you use a function like require(), loadfile() etc. Neither lua nor chdk have the smarts to dynamically load in parts of the source.

The source isn't reloaded into memory less you go into the menu and select again, or restart the camera.

I'm not sure the above explains your observations, but in any case, I think it is not related to the original problem, and so should be discussed in a different thread if you believe there's a real bug involved.

I very much doubt the original problem discussed in this thread is a hardware issue, but being unable to reproduce it I don't have many options for debugging. As mentioned in this post: http://chdk.setepontos.com/index.php?topic=8273.msg90847#msg90847 I was unable to reproduce it on the camera I have an external power supply for.
Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: help: how to debug script interrupting?
« Reply #96 on: 18 / November / 2012, 01:10:46 »
Thanks for all the good info. Can you tell me how CHDK ends up with the same script in memory after you shut down the camera and restart it? Does CHDK write a binary file somewhere on the card and reload it? Does that binary include the compiled Lua script in memory before the last shut down?  Or more generally, where does CHDK store persistent data? Thanks.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline outslider

  • *****
  • 762
Re: help: how to debug script interrupting?
« Reply #97 on: 18 / November / 2012, 02:52:16 »
CHDK doesn't store the script code anywhere else than in RAM. As Reyalp said it is loaded into RAM once the script is chosen from filebrowser or when camera is turned on. When you turn off the camera the script is flushed away and it stays only on SD card as it was saved.

However, CHDK stores the presistent data, including script parameters, in config file (this one with .CFG extension in CHDK/ directory). This file is changed when you change script parameters. So when you set a parameters for some script, then turn off camera, change the script on computer and turn the camera once again the CHDK will load new script version, but the old script parameters. This can cause some bugs when you have changed parameters meaning, added some new params or removed them.

Nevertheless - this is not to be discussed here...
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline Alarik

  • **
  • 83
Re: help: how to debug script interrupting?
« Reply #98 on: 18 / November / 2012, 06:40:43 »
Quote from: lapser on 17 / November / 2012, 17:07:27
You mean you remove the SD card with the power on? On my cameras, opening the door to get to the card cuts the power. And the Lua interpreter might be loading chunks of code as it needs them, if the whole script doesn't fit into memory.

I have a SD card extension cable like this one (http://www.alibaba.com/product-gs/340151552/Patented_GPS_SDHC_Card_Extension_Cable.html) that lets me remove the card without opening the door.
Logged
*

Offline Alarik

  • **
  • 83
Re: help: how to debug script interrupting?
« Reply #99 on: 18 / November / 2012, 06:57:19 »
Quote from: Alarik on 17 / November / 2012, 08:40:33
However I'll try to let them run with just batteries to the doublecheck the "powersupply" problem.
I'll post the results.
Thanks.

Just tried with batteris and after about 15 min I encountered again the bug... so it seems not to be a power supply problem...
Logged
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 23   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal