- cams with DryOS r52 and higher (but I could be wrong)Since the exact models are not known (and things can change in future), I think using the sigfinder for detecting the correct argument count would make the most sense. I'm not sure what the sigfinder should output, though.
I ran into this in finsig_thumb2, it finds the two argument form as DebugAssert2, and the 3 argument form as DebugAssert (it should probably reversed for compatibility with most cams). Both are present on the Digic 6 cameras, I haven't checked on older firmware.
I think on newer cams the additional argument is numeric.
Quote from: srsa_4c on 12 / October / 2017, 17:31:14Since the exact models are not known (and things can change in future)Could there be a way (e.g from the community) to know better now?
Since the exact models are not known (and things can change in future)
it's possible to make that list using firmware dumps and some code.
Quote from: srsa_4c on 13 / October / 2017, 18:37:31it's possible to make that list using firmware dumps and some code.The list of supported models using 3-argument DebugAssert is:ixus145_elph135ixus150_elph140ixus160_elph160ixus30_sd200ixus40_sd300sx170issx400issx410issx510hssx520hssx530hs+ all DIGIC 6 cams (did not actually check this)Partial patch is attached - finsig_vxworks, finsig_dryos, wrappers.cSigfinder outputs a variable (DEF_CONST), the CHDK DebugAssert wrapper decides the correct order of arguments at runtime. This could probably be done better, so suggestions are welcome. I did this to avoid manual changes to port-specific files.
Quote from: srsa_4c on 20 / October / 2017, 18:26:50Quote from: srsa_4c on 13 / October / 2017, 18:37:31it's possible to make that list using firmware dumps and some code.The list of supported models using 3-argument DebugAssert is:ixus145_elph135....ixus160_elph160.....New patch attached. I've almost done testing, so unless there are questions/concerns I'll try and commit this in a few days.Edit2: Update patch, found an edge case in suba_free that was not handled correctly.Phil.
Quote from: srsa_4c on 13 / October / 2017, 18:37:31it's possible to make that list using firmware dumps and some code.The list of supported models using 3-argument DebugAssert is:ixus145_elph135....ixus160_elph160.....
Edit4: Last patch before I add this to SVN. Changed the free list logic to make alloc/free simpler. The getmeminfo values are mostly maintained dynamically instead of being calculated in each call to getmeminfo.
=t={} i=1 repeat t[i]=string.rep(tostring(math.random(0xffff)),math.random(1,3)) i=i+1 until get_meminfo('exmem').free_block_max_size < 100 or i > 20000 return i,get_meminfo('exmem')
allocated_size=150080, free_size=236000, free_block_count=6, free_block_max_size=24,
con 33> =t={} i=1 repeat t[i]=string.rep(tostring(math.random(0xffff)),math.random(1,3)) i=i+1 until get_meminfo('exmem').free_size < 1000 or i > 20000 return i,get_meminfo('exmem')34:return:400134:return:table:...free_size=924allocated_size=357988,free_block_count=44,allocated_count=3485,free_block_max_size=208
free_size=270768allocated_size=116360free_block_count=1,allocated_count=1,free_block_max_size=270768,total_size=387216
I tried to do some general stress testing by allocating enough memory in lua to run through exmem, and got some odd results in get_meminfoTest case in chdkptp isCode: [Select]=t={} i=1 repeat t[i]=string.rep(tostring(math.random(0xffff)),math.random(1,3)) i=i+1 until get_meminfo('exmem').free_block_max_size < 100 or i > 20000 return i,get_meminfo('exmem')This generates a bunch of random strings until free_block_max_size gets below 100 (with a 20000 iteration limit just for sanity)Doing this, it returns after a ~600 iterations with exmem meminfo likeCode: [Select] allocated_size=150080, free_size=236000, free_block_count=6, free_block_max_size=24,Which doesn't make much sense to me, since ~230K in 6 free block should leave at least one bigger than 24.
Could this be caused by the PTP code that allocates 1/2 the largest free block size and then releases it?
A few other general thoughts:One thing about using Canon asserts from CHDK code is it leaves evidence of CHDK in ROM, which conceivably be noticed by Canon service. OTOH, regular crashes where we trigger an exception or assert indirectly show up there anyway. IIRC some parts of the wiki said "canon will never know without the SD card" but this is not strictly true.I'm not particularly worried about this, but I'd be interested if others have opinions. If there were concerns, we could control what our assert wrapper does at runtime.
Incorrect CAM_3ARG_DebugAssert definitions would very likely go unnoticed. Probably not a big deal.Should this be backported to 1.4? It's a significant crash bug, which argues for yes, but the suba re-write makes me a bit nervous, and there will be some conflicts involving the ports that aren't in 1.4.
I'd probably up the semaphore timeout once we're satisfied it's working. If it times out it means something went very wrong, so hanging for ~1 sec should be no issue. I worry that there might be rare cases where shooting could keep something being scheduled for 200ms.
Not sure if it was intended to be, but SUBA_MAGIC doesn't seem to be checked. A similar check value at the end of the pool might also be good.
suba_init enforces size > 2048. Conceivably, I think CHDK in ARAM could leave less than that (but probably shouldn't, since minor changes might push it over the edge) We could skip the ARAM heap in that case.
Started by superfly Feature Requests
Started by artanim Creative Uses of CHDK
Started by indian22 « 1 2 3 4 5 » General Discussion and Assistance
Started by ghust10 RAW Shooting and Processing
Started by amavroidis « 1 2 ... 5 6 » General Discussion and Assistance
