Are these software upgrades possible? - page 7 - General Help and Assistance on using CHDK stable releases - CHDK Forum

Are these software upgrades possible?

  • 187 Replies
  • 52158 Views
*

Offline reyalp

  • ******
  • 14128
Re: Are these software upgrades possible?
« Reply #60 on: 15 / May / 2011, 01:49:25 »
Advertisements
Here is the most recent error:
Code: [Select]
19:36:01 .shoot()
19:36:03 .shoot()
19:36:03 syntax
19:36:05 .shoot()
The syntax error is quite strange. If it is actually a syntax error, you should get something more than that. It could happen if lua fails to execute for some other reason.

Quote
What is the next step in fixing this? What experiments can I try that will give us the info needed to move forward?

As I said before
Quote
The romlog is much more useful with the core/main.bin (or core/main.dump) from the build that was running at the time of the crash. If you built it yourself, just posting the core/main.bin from that build will work. Otherwise, I can make you a build for testing from the chdk or chdkde source tree, but I need to know how the build you are currently using is configured.
Right now, I can't see what parts of CHDK your romlogs correspond to. I had a quick look at the ROM address in the dump, but I didn't see anything obviously interesting there.

If you can narrow down the sequence of events necessary to trigger the problem, that might provide some useful clues. Without know the details of what you are doing, I can't really offer specific suggestions on how to go about that.
Don't forget what the H stands for.

Re: Are these software upgrades possible?
« Reply #61 on: 15 / May / 2011, 08:31:19 »
Quote
If you can narrow down the sequence of events necessary to trigger the problem, that might provide some useful clues.
All I'm doing is sending lua commands over and over, with the exact same timing and sequence every time. it always works for a while, then eventually crashes for no obvious reason. It has crashed with the .shoot() command, the reboot command, and one of the .press "<button>" commands. It doesn't seem to matter what the commands is. It seems to be about how many commands the camera has already processed or how long the camera has been on. If a certain amount of time has gone by, the memory is corrupted or full and it crashes. The commands being sent and the timing of those commands are fine I would think because, most of the time, they work.

How do I test for memory leaks and or find out how or why the memory is getting corrupted?
« Last Edit: 15 / May / 2011, 09:12:38 by John1234 »

Re: Are these software upgrades possible?
« Reply #62 on: 15 / May / 2011, 12:52:20 »
The following info will give you all the info you need. The following commands are the only commands sent. It takes 50 pics, downloads them, deletes them, reboots, repeats. Over and over and over, 24/7. The following is an example of this cyle:
Code: [Select]
01:14:45 .shoot()
04:29:08 .shoot()
04:29:10 .shoot()
04:29:12 .shoot()
04:29:13 .shoot()
05:38:09 .shoot()
05:38:11 .shoot()
05:38:17 .shoot()
07:12:42 .shoot()
07:12:43 .shoot()
07:17:50 .shoot()
07:17:52 .shoot()
07:18:02 .shoot()
07:18:04 .shoot()
07:18:05 .shoot()
07:43:24 .shoot()
07:48:26 .shoot()
08:20:51 .shoot()
08:20:53 .shoot()
08:20:57 .shoot()
08:25:00 .shoot()
08:25:02 .shoot()
08:25:04 .shoot()
08:54:21 .shoot()
08:54:23 .shoot()
08:54:25 .shoot()
08:54:29 .shoot()
09:10:27 .shoot()
09:18:52 .shoot()
09:18:53 .shoot()
09:19:45 .shoot()
09:19:47 .shoot()
09:19:49 .shoot()
09:19:51 .shoot()
09:20:51 .shoot()
09:20:53 .shoot()
09:21:33 .shoot()
09:21:35 .shoot()
09:21:36 .shoot()
09:21:38 .shoot()
09:21:40 .shoot()
09:21:42 .shoot()
09:22:16 .shoot()
09:22:44 .shoot()
09:22:46 !chdku.downloaddir("A/DCIM/100_0515","C:/Zoom Cam Images/20110515/09 22 45")
09:23:46 lua switch_mode_usb(0)
09:23:51 lua click "menu"
09:23:51 lua click "down"
09:23:52 lua click "down"
09:23:52 lua click "down"
09:23:52 lua click "set"
09:23:53 lua click "down"
09:23:53 lua click "down"
09:23:53 lua click "set"
09:23:54 lua click "right"
09:23:54 lua click "set"
09:24:04 reboot
09:24:14 lua switch_mode_usb(1)
09:24:24 .press "zoom_in"; sleep(1500); release "zoom_in"
that cylce of commands repeats over and over. it normally fails on the shoot command as described below:

today it crashed again like this:
Code: [Select]
11:18:34 .shoot()
11:18:36 .shoot()
11:18:38 .shoot()
11:18:40 .shoot()
11:18:43 .shoot()
11:18:44 failed
11:18:44 .shoot()
11:18:44 failed
11:18:46 .shoot()
11:18:46 failed
Here is the romlog:
Code: [Select]
Exception!! Vector 0x10
Occured Time  2011:05:15 10:19:42
Task ID: 36110410
Task name: PTPSessionTA0
Exc Registers:
0x03B44FEB
0x03B44FE9
0x00000000
0x00000001
0xE1A00000
0x03BF0B98
0x00000000
0x00000000
0xFFFFFFFF
0x0000587C
0x0027F018
0x19980218
0x03B1F909
0x00334D50
0x03B2C5F1
0x03B2E678
0xA0000033
StackDump:
0x03C03A78
0x03B44FEB
0x03C03908
0x03C03908
0x00334DB4
0x00334D7C
0x03B44FEB
0x03B2C5F1
0x03B44FEB
0x00000001
0x03C03A80
0x00334DB8
0x03C03F30
0x03B2EB5D
0x00334EB8
0x00334E24
0x00334DB8
0x0000003D
0x00335508
0x00000001
0x00000105
0x03B2C709
0x00334DB4
0x03B32289
0x03B44FEB
0x0000003D
0x00000000
0x00335508
0x03C03908
0x03B2CEEB
0x00335508
0x00334E20
0x03B2CF15
0x03B2D0A1
0x00335508
0x03B2DA29
0x03B2D843
0x03B31C77
0x03B32835
0x00335518
0x00334EB8
0x00334EB8
0x00334E24
0x00000001
0x00000105
0x03B31D4B
0x00000000
0x00335508
0x00335508
0x00334EB8
0x00000105
0x03B2DAC9
0x00000000
0x00000008
0x00000013
0x00335508
0xFFFFFFFF
0xFFFFFFFF
0x00335508
0x00000019
0x0000000F
0x03B2DC31
0x00335508
0x00000000
0x03B2DC59
0x00335508
0x00334EB8
0x03B2DCA1
0x00000000
0xFFFFFFFF
0x00000005
0x00335508
0x00000018
0x03B2DCD1
0x00335508
0x00334EB8
0x03B2DD11
0x00000003
0x0000000D
0x00335508
0x00000003
0x00000000
0x003351EC
0x03B2DBBB
0x00335508
0x00000000
0x03B2DC59
0x00335508
0x00000001
0x03B2D2E1
0x03C03ED8
0x03C03F30
0x00335254
0x00335508
0x03C03908
0x00334E60
0x0000003A
0x00000038
0xFFFFFFFF
0x00000006
0x00000014
0x00000000
0x03060006
0x00335244
0x03C005F0
0x00334F28
0x003354F8
0x03B3158B
0x03B2CE97
0x0003FFFF
0x03B44B33
0x00000004
0x003351F0
0x003354F8
0x00000001
0x00000000
0x003351F0
0x03B2D305
0x03C00718
0x03C00770
0x00335244
0x003354F8
0x03BF0B30
0x00000000
0x0000003A
0x00000038
0xFFFFFFFF
0x00000003
02262530: UI:ScreenUnLock

02262550: UI:DisplayPhysicalScreenCBR

02263310: UI:ShootSeqToUI:0x2006:adr:0,Para:0

02263310: UI:ShtCon_SetPreCapt

02263320: UI:Strobe:Close

02263320: UI:DSIC:62,0

02263320: UI:ScreenLock

02263330: SS:IsCharge=1

02263330: SS:StartFcsChk

02263390: UI:ScreenUnLock

02263420: UI:_ResetShootingMode

02263420: UI:ChangePopupStrobe:Close

02263420: SS:PopChg

02263420: UI:_EntryPrepareShoot

02263420: UI:ShootState:0x7

02263420: UI:DisplayPhysicalScreenCBR

02263670: UI:Button:0x000009A3:PressSwTwo

02263670: UI:ShootState:0x8

02263670: UI:ShootState:0x9

02263670: UI:ShtCon_ContiShootPicture

02263680: UI:ChangePopupStrobe:Close

02263680: SS:PopChg

02263680: UI:DSIC:14,0

02263690: UI:_MuteOn

02263690: UI:DSIC:43,0

02263690: UI:DispSwCon_MuteOnPhysicalScreen

02263690: UI:MuteOnPhysicalScreen

02263690: SS:Shoot

02263690: UI:DSIC:63,0

02263700: UI:ScreenLock

02263710: UI:Button:0x000009A4:UnpressSwTwo

02263710: UI:Button:0x000009A2:UnpressSwOne

02263720: SS: Raw[1]

02263720: SS: Raw[1]

02263720: UI:ScreenUnLock

02263740: UI:ShootSeqToUI:0x2022:adr:0,Para:0

02263740: UI:ScreenLock

02263740: UI:ScreenUnLock

02263760: UI:DisplayPhysicalScreenCBR

02263760: UI:DSIC:64,0

02263760: UI:DisplayPhysicalScreenCBR

02264520: UI:ShootSeqToUI:0x2008:adr:0x64f0,Para:25840

02264520: UI:_MuteOff

02264520: UI:DSIC:44,0

02264520: UI:DispSwCon_MuteOffPhysicalScreen

02264520: UI:MuteOffPhysicalScreen

02264520: UI:ScreenLock

02264530: UI:ScreenUnLock

02264530: UI:ShootState:0xA

02264530: UI:ShtCon_StartReview

02264530: UI:ShootState:0xC

02264530: SS:ExitShoot

02264530: UI:_EntryPrepareRecreviewOff

02264530: UI:ShootState:0xB

02264530: UI:ShtCon_StopReview

02264530: UI:_fReservExitConti

02264530: UI:DisplayPhysicalScreenCBR

02264650: UI:DSIC:47,0

02264660: UI:ShootSeqToUI:0x2007:adr:0x64f0,Para:25840

02264660: UI:ShootSeqToUI:0x2001:adr:0,Para:0

02264660: UI:Sht_CancelStrobeChargeTimer

02264660: UI:DSIC:4c,0

02264670: UI:_CaptureStanbyForReview

02264670: UI:DSIC:46,0

02264670: UI:ShootSeqToUI:0x201e:adr:0x64f0,Para:25840

02264670: UI:_ExitContiSequence

02264670: SS:StopContiShoot

02264680: UI:ShootSeqToUI:0x2018:adr:0xfffffffb,Para:-5

02264680: UI:ShootSeqToUI:0x2001:adr:0,Para:0

02264680: UI:Sht_CancelStrobeChargeTimer

02264680: UI:DSIC:4c,0

02264680: UI:Sht_CancelStrobeChargeTimer

02264680: UI:DSIC:4c,0

02264680: UI:_CaptureStanbyForReview

02264680: UI:ShootSeqToUI:0x2029:adr:0x64f0,Para:25840

02264680: UI:_ExitSequence

02264680: UI:Sht_CancelStrobeChargeTimer

02264680: UI:DSIC:4c,0

02264690: SS:StopFcsChk

02264690: SS:CancelPre

02264700: SS:NextAvail(7),ReviewAvail(5)

02264770: UI:ScreenLock

02264770: UI:ScreenUnLock

Quote
Without know the details of what you are doing
You now know all of the details. There are no more details be be had. Now can we finally move on to fixing it?
« Last Edit: 15 / May / 2011, 12:59:11 by John1234 »

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Are these software upgrades possible?
« Reply #63 on: 15 / May / 2011, 13:54:32 »
Did you try to replace shoot() with more realistic button press oriented option as reyalp suggested earlier, such as:

press("shoot_half"); repeat sleep(10) until get_shooting() == true; press("shoot_full"); sleep(10); release("shoot_full"); sleep(10); release("shoot_half")

(note: I didn't test that so at the very least my repeat loop syntax could be wrong for single line use).

Re: Are these software upgrades possible?
« Reply #64 on: 15 / May / 2011, 15:15:22 »
It doesn't just crash on .shoot() though. sometimes it crashes on reboot, a random press "<button>" command, .shoot(). it doesn't seem to be tied to any particular command. It is like it gradually leaks memory and then crashes. You think the .shoot() command is causing a memory leak??

*

Offline reyalp

  • ******
  • 14128
Re: Are these software upgrades possible?
« Reply #65 on: 15 / May / 2011, 15:40:56 »
The following info will give you all the info you need
Well no, actually it isn't. As I said several times before
Quote
The romlog is much more useful with the core/main.bin (or core/main.dump) from the build that was running at the time of the crash. If you built it yourself, just posting the core/main.bin from that build will work. Otherwise, I can make you a build for testing from the chdk or chdkde source tree, but I need to know how the build you are currently using is configured.
Without that, your romlogs are pretty much useless. Of course, it is possible that even with this nothing useful be learned  from the romlog. Don't know until we try.

Knowing what build you are using could also suggest other debugging options.
Quote
You now know all of the details. There are no more details be be had. Now can we finally move on to fixing it?
What do you mean "we" ? You are welcome "move on to fixing it" any time.

If you want me to fix it you need to understand that I do this in my spare time. I'm trying to help you, but I won't necessarily be able to debug your problem. Debugging remotely is difficult in the best of times.

There are many things that you could do to narrow down the possible causes of the problem:
- try fudgeys suggestion
- try find any pattern in when the error occurs (how many shots/download cycles). Knowing whether it shows up completely randomly, or whether it gets increasingly common over time might be a clue.
- try running the same cycle, but not actually shooting. E.g. if you do .print('shoot') instead of shoot, does it still crash eventually ? You should be able to run this much faster than actual shooting. You can't do the delete, but you could still have the download and mode switch.
- monitor available memory on the camera with get_meminfo between shots
- hack some debug logging into the CHDK C code (in the ptp and script execution path). You can write to the camera console log, which will be captured when the crash occurs.

Don't forget what the H stands for.

Re: Are these software upgrades possible?
« Reply #66 on: 15 / May / 2011, 21:05:35 »
Quote
The romlog is much more useful with the core/main.bin (or core/main.dump)
Ok I can get that with this command right? d A/core/main.bin

I took the CHDK folder from some other camera (SX200 I believe) and the .bin and .f12 firmware files in the root directory were from the forum on the SX130IS since there was no official build yet.

Quote
- try find any pattern in when the error occurs (how many shots/download cycles). Knowing whether it shows up completely randomly, or whether it gets increasingly common over time might be a clue.
There is no pattern other than the fact that it never crashes immediately. It is always able to go through about one and a half cycles. As I'm typing this it has done 4 cycles without crashing which is pretty surprising.

Quote
- monitor available memory on the camera with get_meminfo between shots
now we're talkin'. I thought an OS isn't able to detect leaks that's why they are called leaks. What is the usage example for get_meminfo?

Quote
- hack some debug logging into the CHDK C code (in the ptp and script execution path). You can write to the camera console log, which will be captured when the crash occurs.
I don't have an understanding of the overall file architecture nor am I familiar enough with C to know how to add debugging code in there. C# I get, but not C.




*

Offline reyalp

  • ******
  • 14128
Re: Are these software upgrades possible?
« Reply #67 on: 15 / May / 2011, 22:10:31 »
Quote
The romlog is much more useful with the core/main.bin (or core/main.dump)
Ok I can get that with this command right? d A/core/main.bin
No. This is something you would have if you compiled your own copy of CHDK. If you did not, then I need to know which build you are using. From the forum... I'm guessing:
http://chdk.setepontos.com/index.php?topic=5691.msg65693#msg65693 ?

I'll post some builds shortly.
Quote
There is no pattern other than the fact that it never crashes immediately. It is always able to go through about one and a half cycles.
Sounds like a pattern to me. This suggests the download/delete/reboot cycle might have something to do with it. You could try say 300 photos without a download/delete and see if it crashes. You could also try the whole cycle with say 1 photo each time, and see if it still crashes after a few cycles.

Just to be clear, I'm not suggesting any of the above as a solution.  It's just a way of maybe narrowing down the causes.
Quote
Quote
- monitor available memory on the camera with get_meminfo between shots
now we're talkin'. I thought an OS isn't able to detect leaks that's why they are called leaks. What is the usage example for get_meminfo?
It looks like the build you are using is from before this was implemented. It doesn't detect memory leaks, but it can tell you how much is free. I'll post instructions with my build.
Quote
I don't have an understanding of the overall file architecture nor am I familiar enough with C to know how to add debugging code in there. C# I get, but not C.
Fair enough. That limits your options, but if I'm making builds anyway I may be able to throw some useful things in there.

Don't forget what the H stands for.

Re: Are these software upgrades possible?
« Reply #68 on: 16 / May / 2011, 00:06:19 »
Quote
I need to know which build you are using. From the forum... I'm guessing:
http://chdk.setepontos.com/index.php?topic=5691.msg65693#msg65693 ?
I think so. I didn't use the CHDK folder that came with it though. (I don't know why.) I'm going to put that one on the SD card anyway just in case that wasn't the one. (Not the DE build. The one above it.)
« Last Edit: 16 / May / 2011, 00:14:42 by John1234 »

*

Offline reyalp

  • ******
  • 14128
Re: Are these software upgrades possible?
« Reply #69 on: 16 / May / 2011, 00:11:42 »
Here's a build to test. It is compiled without exmem. Exmem might be the source of your memory corruption, but from what I understand this camera has very little free RAM and so CHDK didn't work well without exmem. I've turned off as many compile-time optional features as I could to reduce memory usage.

Please check how much memory is free after start. You can do this in chdkptp with
Code: [Select]
con>  !return chdku.execwait('return get_meminfo()')
You don't need to add this to the script, just run it once after loading this build. edit: and post the output here

I've added some logging code also tracks free memory each time a script runs. This will show up in the crash log if it crashes.
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal