supplierdeeply

serious chdk bug

  • 8 Replies
  • 8016 Views
*

Offline chr

  • ***
  • 138
  • IXUS 82 IS
  • Publish
    serious chdk bug
    « on: 21 / September / 2008, 10:28:04 »
    Advertisements
    Hello!

    Q: "Can chdk damage the cam?"
    A: Actually it can ...

    While bugfixing manual focus (SD Mode) in my porting sd1100 branch I discovered a serious bug:

    This feature also tries to work in PLAY mode even when the lens is not out and I can hear some mechanical activity  :o
    Hacki just confirmed that with his cam.

    I also expect the same trouble using "set_zoom". This ubasic function calls _MoveZoomLensWithPoint() without any checks! (Actually set_zoom is still broken in my port, and I don't want to try this in PLAY mode)



    *

    Offline Hacki

    • ****
    • 353
    • SX100
  • Publish
    Re: serious chdk bug
    « Reply #1 on: 21 / September / 2008, 10:46:56 »
    Well. The cam does some obnoxious squeaking noise, as if a motor is trying to move something which is stuck - does not sound very healthy. I did it twice, the focus still works fine. Of course it wont lengthen the lifespan of the camera, but i doubt it will cause any serious damage immediately..

    I was insane enough to test what set_zoom does in playback mode - nothing at all, the camera just turns off. (SX100, dryos cam, who knows, maybe VxWorks cameras will explode ;) )

    *

    Offline chr

    • ***
    • 138
    • IXUS 82 IS
  • Publish
    Re: serious chdk bug
    « Reply #2 on: 21 / September / 2008, 11:26:56 »
    The difference is, that "manual focus" uses _SetPropertyCase()
    and set_zoom uses a ROM function which obviously does an assert() check!

    Here is what I get when using set_zoom (in REC mode, it's bugged in my port):
    Code: [Select]
    ASSERT!! FocalLengthConverter.c Line 168
    Occured Time  2008:09:21 14:54:59
    Task ID: 11993113
    Task name: PhySw
    SP: 0x00117D8C
    StackDump:
    0x00000000
    0x00000000
    0x00000017
    0x00000080
    0x000DCBFC
    0x00000000
    0x00117DE4
    0x000085DC
    0x002877E0
    0x00000800
    0x00000040
    0x00117D8C
    0xFF821DF0
    0x00000000
    0xFF8162E4
    0xFF8162E4
    0x00117D8C
    0xFFA1C854
    0x000000A8
    0x00000007
    0x0000C450
    0x000085DC
    0x00000007
    0x00007530
    0x00000000
    0x00000000
    0x19980218
    0x000E0284
    0xFFA1C6BC
    0x00000001
    0xFFA238B0
    0x000085DC
    ShootConDump:
    10 00 01 02 07 00 00 0f 0f 0f
    CameraConDump:
    0a 01 02 0e 0a 01 11 0b 02 0e
    00168000: Window:IneffectiveLockPhysicalScreen
    00168010: SSAPI::CaptureModeChange
    00168010: SSAPI:: EvfMode = 0
    00168010: SSAPI:: CaptMode = 0x8004
    00168060: SSAPI::CompleteCaptureModeChange
    00168070: _DecideCaptureMode
    00168070: _StartStill
    00168070: SSAPI:: UsingRaw[0]
    00168070: DSIC:41,6
    00168130: Window:IneffectiveLockPhysicalScreen
    00168130: _MuteOffStitch
    00168130: TerminateDeliverToZoomController
    00168130: OPTICAL_ZOOM_MIN_POS
    00168130: ST_OPTICAL_WIDE_TERM
    00168130: UnpressZoomLever
    00168130: DispSwCon_TurnOnDisplayDevice
    00168130: LogicalEvent:0x313d:adr:0,Para:0
    00168130: _EntryStartRecMode
    00168140: CaptModeChanger_CheckRTCRrepared
    00168140: DispSw: Unlock
    00168140: DispSwCon_MuteOffPhysicalScreen
    00168140: MuteOffPhysicalScreen
    00168140: _DecideModeDial
    00168140: No Change Capture Mode
    00168150: LogiEvnt_NotPowerType:0x09a4:adr:0,Para:0
    00168150: LogiEvnt_NotPowerType:0x09a2:adr:0,Para:0
    00171880: PressSwOne
    00171880: SSAPI::PrepareBuffer
    00171880: SSAPI::UpdateCaptureBitRate
    00171880: SSAPI:: UsingRaw[0]
    00171880: ShootState:0x1
    00171880: ShtCon_Activate
    00171880: DispSw: Lock
    00171880: ShtCon_PrepareCapture
    00171880: DSIC:61,0
    00171890: Window:EffectiveLockPhysicalScreen
    00171890: Window:IneffectiveLockPhysicalScreen
    00171890: LogicalEvent:0x3135:adr:0,Para:0
    00171890: SSAPI::PrepareCapture
    00171920: ShootState:0x2
    00171920: ClearEventComp
    00172250: ShootSeqToUI:0x2006:adr:0x1,Para:1
    00172250: ShtCon_SetPreCapt
    00172250: ShtIsoChg
    00172250: DSIC:62,0
    00172250: Window:EffectiveLockPhysicalScreen
    00172310: Window:IneffectiveLockPhysicalScreen
    00172320: _ResetShootingMode
    00172320: _EntryPrepareShoot
    00172320: ShootState:0x7
    00172730: UnpressSwOne
    00172730: _ExitSequence
    00172730: Sht_CancelStrobeChargeTimer
    00172730: DSIC:4b,0
    00172730: SSAPI::CancelPrepare
    00172900: SS:StrobeChargeComplete
    00172910: DispSwCon_MuteOffPhysicalScreen
    00172910: MuteOffPhysicalScreen
    00172910: ShootState:0x0
    00172910: ShtCon_Deactivate
    00172910: DSIC:14,0
    00172910: DSIC:60,0
    00172910: DispSwCon_TurnOnDisplayDevice
    00172910: Window:EffectiveLockPhysicalScreen
    00172940: SSAPI:: UsingRaw[0]
    00172990: Window:IneffectiveLockPhysicalScreen
    00173000: DispSw: Unlock
    00173000: DispSwCon:Unlock
    00173000: ShtIsoChg
    00173000: TerminateDeliverToZoomController
    00173000: OPTICAL_ZOOM_MIN_POS
    00173000: ST_OPTICAL_WIDE_TERM
    00173000: UnpressZoomLever
    00173000: _EntryIdleShoot
    00173000: ShootState:0x0
    00173000: SSAPI:: UsingRaw[0]
    00173750: Window:IneffectiveLockPhysicalScreen
    00177310: Window:IneffectiveLockPhysicalScreen
    00191890: Window:IneffectiveLockPhysicalScreen
    00195990: Window:IneffectiveLockPhysicalScreen

    If you implement the ROMLOG feature for your cam (I saw evidence for this in vxwork, too), you will have a similar crash log. The default actions of the exception handlers are writing this info to ROM (sic!) and switch off the cam.
    « Last Edit: 21 / September / 2008, 11:32:52 by chr »

    *

    Offline PhyrePhoX

    • *****
    • 2253
    • make RAW not WAR
      • PhyreWorX
  • Publish
    Re: serious chdk bug
    « Reply #3 on: 21 / September / 2008, 11:30:59 »
    This is exactly the reason i added get_mode to the range of ubasic commands. Using it,scripts can check which mode they are run under and exit if requirement isnt met.


    *

    Offline chr

    • ***
    • 138
    • IXUS 82 IS
  • Publish
    Re: serious chdk bug
    « Reply #4 on: 21 / September / 2008, 11:36:54 »
    This is exactly the reason i added get_mode to the range of ubasic commands. Using it,scripts can check which mode they are run under and exit if requirement isnt met.

    This doesn't fix the problem! To my mind, the scripting should be bullet proof. (however, theres peek and poke in lua, right?) (script options: [ ] allow unsafe functions)

    Without script, you can also activate SD mode in PLAY, and engage the mechanic!!!

    Power on in play, press alt, up, (left/right/zoom depending on cam model) -> squeezy noise !


    *

    Offline reyalp

    • ******
    • 9882
  • Publish
    Re: serious chdk bug
    « Reply #5 on: 21 / September / 2008, 15:25:25 »
    This is exactly the reason i added get_mode to the range of ubasic commands. Using it,scripts can check which mode they are run under and exit if requirement isnt met.

    This doesn't fix the problem! To my mind, the scripting should be bullet proof. (however, theres peek and poke in lua, right?) (script options: [ ] allow unsafe functions)
    In practice, it would be very difficult to restrict "unsafe" if by unsafe you mean crash the cam. Things that can do physical damage OTOH or write to flash we should avoid. Poke sort of falls in this category, but you have to go out of your way to do it (or blindly run a script).

    It would be quite easy to add an "allow unsafe" checkbox, figuring out what all is unsafe is a different story. Actually, the CHDK shooting code should probably check that you are actually in record mode for every function.

    Quote
    Without script, you can also activate SD mode in PLAY, and engage the mechanic!!!

    Power on in play, press alt, up, (left/right/zoom depending on cam model) -> squeezy noise !
    We should definitely try to avoid this.

    CHDK can *definitely* damage your camera.
    Don't forget what the H stands for.

    *

    Offline chr

    • ***
    • 138
    • IXUS 82 IS
  • Publish
    Re: serious chdk bug
    « Reply #6 on: 21 / September / 2008, 15:28:00 »
    so, I fixed set_zoom for sd1100
    ubasic script using set_zoom now runs fine on my cam.

    This happens while set_zoom in PLAY mode and lens is in:

    Code: [Select]
    ASSERT!! ZoomLensController.c Line 207
    Occured Time  2008:09:21 20:06:18
    Task ID: 11993113
    Task name: PhySw
    SP: 0x00117DB0
    StackDump:
    0x00000000
    0x00000000
    0x00000017
    0x00000080
    0x000DCC14
    0x00000000
    0x00117E08
    0x000085DC
    0x002877E0
    0x00000800
    0x00000040
    0x00117DB0
    0xFF821DF0
    0x00000000
    0xFF8162E4
    0xFF8162E4
    0x00117DB0
    0xFF92F024
    0x000000CF
    0x00000000
    0xFFA238B0
    0x000085DC
    0x00000006
    0x00007530
    0x00000000
    0x00000000
    0x19980218
    0x000E029C
    0xFF92F27C
    0x00000008
    0x0000FFFF
    0x00000000
    ShootConDump:
    0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
    CameraConDump:
    08 0b 02 0f 0f 0f 0f 0f 0f 0f
    00000050: *** Camera Log Start ***

    00000060: WriteEnableMedia

    00000070: _BeforeCBRForPlay

    00000070: _AfterCBRForPlay

    00000070: DSIC:52,0

    00000070: LogicalEvent:0x5003:adr:0,Para:0

    00000080: LogicalEvent:0x1165:adr:0,Para:0

    00000080: _StartupImage

    00000080: SetPanelBrightnessToLcdController

    00000080: SetDisplayType

    00000080: TurnOnDisplayForStartup

    00000080: LogicalEvent:0x5007:adr:0,Para:0

    00000100: SSAPI::NotifyStartupImageCreated

    00000100: DispSwCon_TurnOnBackLight

    00000100: TurnOnBackLight

    00000140: LogicalEvent:0x5001:adr:0,Para:0

    00000170: DispSwCon_MuteOffPhysicalScreen

    00000170: MuteOffPhysicalScreen

    00000170: Window:EffectiveLockPhysicalScreen

    00000170: Window:IneffectiveLockPhysicalScreen

    00000170: LogicalEvent:0x300a:adr:0,Para:0

    00000180: CreatePBController

    00000180: PB.Create

    00000180: LogicalEvent:0x3138:adr:0,Para:0

    00000370: LogicalEvent:0x5006:adr:0,Para:0

    00000470: LogicalEvent:0x112c:adr:0,Para:0

    00000500: PB.CreateE

    00000500: AC:StartPB

    00000500: DispSwCon_TurnOnDisplayDevice

    00000500: AC:EBtn

    00000500: PB.Start

    00000500: DSIC:46,0

    00000510: LogicalEvent:0x3209:adr:0x3f,Para:63

    00000510: CameraCon_NotifyCompleteFlashJpeg

    00000510: _CallNotifyCompleteFlashJpeg

    00000510: PB.Flash

    00000510: DSIC:46,0

    00000510: Window:EffectiveLockPhysicalScreen

    00000510: DSIC:46,0

    00000670: PB.DrawI

    00000690: LogicalEvent:0x320a:adr:0,Para:0

    00000760: LogicalEvent:0x3203:adr:0,Para:0

    00000790: PB.StartE

    00000790: PB.TOTAL

    00000790: PB.DPOF

    00000790: PB.IHist

    00000800: PB.DcdCBR

    00000800: PB.RfrsI

    00000840: Window:IneffectiveLockPhysicalScreen

    00000840: Window:IneffectiveLockPhysicalScreen

    00000850: Window:IneffectiveLockPhysicalScreen

    00000850: LogicalEvent:0x3201:adr:0,Para:0

    00000850: DispSw: Unlock

    00000850: DispSwCon:Unlock

    00000850: Window:IneffectiveLockPhysicalScreen

    00000860: DispSwCon_TurnOnBackLight

    00000860: DispSwCon_MuteOffPhysicalScreen

    00000860: MuteOffPhysicalScreen

    00000860: AC:EntryPB

    00000860: AP:CheckConnectUSB

    00000960: LogicalEvent:0x321f:adr:0,Para:0

    00000960: PB.CTG

    00000960: DSIC:47,0

    00005410: Window:IneffectiveLockPhysicalScreen

    00006710: Window:IneffectiveLockPhysicalScreen

    00010120: Window:IneffectiveLockPhysicalScreen

    00010780: Window:IneffectiveLockPhysicalScreen

    There are many checks in the ROM before engaging any mechanics ... so better this crash then any damage.

    Doing manual focus uses SetPropertyCase() and no ROM function !

    « Last Edit: 21 / September / 2008, 15:30:38 by chr »

    *

    Offline chr

    • ***
    • 138
    • IXUS 82 IS
  • Publish
    Re: serious chdk bug
    « Reply #7 on: 21 / September / 2008, 15:41:15 »
    In practice, it would be very difficult to restrict "unsafe" if by unsafe you mean crash the cam. Things that can do physical damage OTOH or write to flash we should avoid. Poke sort of falls in this category, but you have to go out of your way to do it (or blindly run a script).

    It would be quite easy to add an "allow unsafe" checkbox, figuring out what all is unsafe is a different story. Actually, the CHDK shooting code should probably check that you are actually in record mode for every function.

    I think, that is doable. Unsafe operations are: peek *), poke, call **), set_property
    All others should have sanity checks. Remember: you can do buffer overflows from scripting if functions are not well implemented!

    To separate this stuff I'm going to suggest to the lua department to use OO style to provide the cam's features. Unsafe operations belongs to a different Object/Class which is simply not present in the scripting environment if "allow unsafe" is not checked.


    *) belongs to debugging
    **) not implemented yet. Want that to explore ROM functions.


    *

    Offline PhyrePhoX

    • *****
    • 2253
    • make RAW not WAR
      • PhyreWorX
  • Publish
    Re: serious chdk bug
    « Reply #8 on: 09 / October / 2008, 13:10:06 »
    i think i fixed this in Changeset 531 - chdk - Trac
    pretty ugly, yet working though

     

    Related Topics