Creating spytask() - General Discussion and Assistance - CHDK Forum supplierdeeply

Creating spytask()

  • 16 Replies
  • 2282 Views
Creating spytask()
« on: 24 / March / 2013, 08:34:41 »
Advertisements
About 40% of the CHDK builds have in boot.c :-

Code: [Select]
void CreateTask_spytask() {
        _CreateTask("SpyTask", 0x19, 0x2000, core_spytask, 0);
};

the rest have (including in /generic/main.c):-

Code: [Select]
void spytask(long ua, long ub, long uc, long ud, long ue, long uf)
{
    core_spytask();
}


void CreateTask_spytask() {
_CreateTask("SpyTask", 0x19, 0x2000, spytask, 0);
}

Why is this ?

I ask because in S100 101a I had forgotten to change it to the second version and the user reported crashing when booting with an autostart script if the dial was set to Custom.
Starting in 'P' mode was OK and you could switch to Custom mode after a few seconds.

After I made the change, there were no problems.
« Last Edit: 24 / March / 2013, 09:10:06 by Microfunguy »

*

Offline srsa_4c

  • ******
  • 4263
Re: Creating spytask()
« Reply #1 on: 24 / March / 2013, 09:29:40 »
Why is this ?
core_spytask() is compiled as thumb code, the Canon firmware is ARM. Maybe something related to thumb/ARM interwork didn't work out. It might be a toolchain related problem.

Perhaps reyalp has a better explanation.

Somewhat related: http://chdk.setepontos.com/index.php?topic=2500.msg97121#msg97121

If you can show a romlog, that could help (with the corresponding core/main.dump).

platform/generic/main.c is only used in VxWorks ports.
« Last Edit: 24 / March / 2013, 09:32:06 by srsa_4c »

Re: Creating spytask()
« Reply #2 on: 24 / March / 2013, 10:32:10 »
Interesting.

I cannot work on this right now but are you saying VxWorks needs an ARM wrapper but DRYOS does not ?


*

Offline srsa_4c

  • ******
  • 4263
Re: Creating spytask()
« Reply #3 on: 24 / March / 2013, 11:04:10 »
are you saying VxWorks needs an ARM wrapper but DRYOS does not ?
No. Canon's DryOS based firmwares are more protected against thumb/ARM calling issues (not because of DryOS, but because of compiler options). Firmware routines which end with a MOV PC, LR instruction can be problematic under certain circumstances. These typically occur in VxWorks based cameras, but even DryOS based ones have some of them.

It's possible that you're just covering some miscompiled (or wrong) code with that wrapper. Hard to tell without that log. Is this vanilla CHDK, or modified in some way?


*

Offline reyalp

  • ******
  • 12690
Re: Creating spytask()
« Reply #4 on: 24 / March / 2013, 16:02:15 »
I think the difference in spytask starting CHDK is just due to the different hooking methods. generic/main.c is only for vxworks, and uses the VxWorks native task hook functions.
Don't forget what the H stands for.

*

Online philmoz

  • *****
  • 3163
    • Photos
Re: Creating spytask()
« Reply #5 on: 24 / March / 2013, 17:51:56 »
Why is this ?
core_spytask() is compiled as thumb code, the Canon firmware is ARM. Maybe something related to thumb/ARM interwork didn't work out. It might be a toolchain related problem.

If this was the case it would fail all the time not intermittently. The core_spytask function never returns so the return instruction isn't relevant. So long as the correct address (with bit 0 set to 1) for core_spytask is linked into the _CreateTask call the processor should switch to Thumb mode correctly.

My guess is that it is a bug somewhere else - possibly a memory buffer overflow. When the alternate version of _CreateTask / spytask is used the code size changes and the functions will get loaded to different memory locations masking the issue somehow.

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)

Re: Creating spytask()
« Reply #6 on: 25 / March / 2013, 07:34:34 »


If you can show a romlog

Attached.



Quote
(with the corresponding core/main.dump).

Attached.

He is using the extend.m romlog script with SDM, not the CHDK menu function.

EDIT:

Attachments updated.
« Last Edit: 25 / March / 2013, 15:28:47 by Microfunguy »

*

Offline srsa_4c

  • ******
  • 4263
Re: Creating spytask()
« Reply #7 on: 25 / March / 2013, 13:54:54 »
Well, my guess is now the same as Phil's. An assert happened in CaptSeqTask, inside a kernel function named ReceiveMessageQueue. It's possible that RAM belonging to kernel got corrupted.

I think that the assert happened with a different build, not the one whose main.bin is attached. The only SDM related address in the stack dump doesn't make sense.

Does it also crash when using CHDK?


Re: Creating spytask()
« Reply #8 on: 25 / March / 2013, 14:00:51 »
I think that the assert happened with a different build

D**n !

I will redo it now.

Quote
Does it also crash when using CHDK?

I will ask him to test.

Another S100 user has a strange problem that should also be tested with CHDK.

After booting, If he changes the ISO (not iso override) then uses the USB remote, the cameras power-down and the lens remains extended.

*

Offline srsa_4c

  • ******
  • 4263
Re: Creating spytask()
« Reply #9 on: 25 / March / 2013, 14:07:27 »
You could provide them with test builds (and keep main.dump), then ask for the romlogs.

 

Related Topics