suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras) - page 6 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 4 5 [6] 7 8   Go Down

suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)

  • 77 Replies
  • 20847 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #50 on: 08 / October / 2017, 00:41:22 »
Advertisements
Quote from: reyalp on 08 / October / 2017, 00:37:31
Quote
I did not get any crashes doing this on my G12 with the new suba code.
Meaning 500 images deleted without problems?


No.


100 images works.
150 images just returns to the chdkptp command prompt, no images deleted.
459 images hangs chdkptp (until the camera is turned off) - no images deleted, no output.


Phil.
Logged
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)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #51 on: 08 / October / 2017, 03:59:54 »
SX150IS

- 500 images on the card, no output from mc:delete_images_list, chdkptp appears to hang.
- 150 images on the card, images deleted successfully
- 300 images on the card, no output from mc:delete_images_list, chdkptp appears to hang.
- 199 images on the card, images deleted successfully

I did not get any crashes doing this with the new suba code.
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #52 on: 08 / October / 2017, 06:28:58 »
I've checked in the required supporting changes (finsig, wrappers, stdlib) to SVN.
Attached patch is just the new suba code.


I've added a 200ms timeout to the TakeSemaphore calls, if it fails a DebugAssert will be thrown. Have not had any so far.
Safety checks are enabled.


Phil.

Logged
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)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline reyalp

  • ******
  • 14034
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #53 on: 08 / October / 2017, 15:22:41 »
Quote from: andrew.stephens.754365 on 08 / October / 2017, 03:59:54
SX150IS

- 500 images on the card, no output from mc:delete_images_list, chdkptp appears to hang.
A couple things could try:
Do the list and and delete separately, e.g.
Code: [Select]
!imglist=mc:imglist()
If that succeeds,
Code: [Select]
!return mc:delete_images_list(imglist,{verbose=true})
verbose=true will cause it to print one line per file removed.

You can use {pretend=true,verbose=true} to see a list of images that would be removed.

Check the on camera CHDK console after failure

In the case of
Quote
150 images just returns to the chdkptp command prompt, no images deleted.
check whether the multicam script is still running on the camera, e.g. with

Code: [Select]
!return mc:cmdwait('tick')
Logged
Don't forget what the H stands for.
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #54 on: 09 / October / 2017, 04:56:57 »
Still using Phil's new suba code, I copied 1000 images (same image as previously used) to, the same, SD card.

Test1:
!imglist=mc:imglist()
!return mc:delete_images_list(imglist,{pretend=true,verbose=true})
!return mc:delete_images_list(imglist,{verbose=false})
result -> deleted all 1000 SD image files.

Test2:
!imglist=mc:imglist()
!return mc:delete_images_list(imglist,{verbose=false})
result -> deleted all 1000 SD image files.

Test3:
!mc:delete_images_list(mc:imglist(),{verbose=false})
result -> deleted all 1000 SD image files.

Test4:
!mc:delete_images_list(mc:imglist(),{verbose=true})
result -> deleted all 1000 SD image files.

None of the tests took particularly long.

I can only imagine, in my previously reported results, that I simply turned the camera off too quickly (haven't experienced Phil's return to command prompt with no images deleted though).
Logged
*

Offline ottokar

  • *
  • 29
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #55 on: 10 / October / 2017, 12:39:58 »
Hi,
 I have a question - this latest patch would be applicable to many different camera models, perhaps even most of them - is that right?

 I remember reading on here that all these multicam setups start off nicely with 2 cameras, then at about 10 cameras they mostly work ok, and then when you have lots of cameras, they can cause quite a lot of headaches - could this semaphore fix perhaps mean that, by avoiding random crashes,  multicam setups become nicely scaleable from 2 to X cameras?

 If so, then that's a really big change,

thanks,
Andrew
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #56 on: 10 / October / 2017, 17:22:36 »
Quote from: ottokar on 10 / October / 2017, 12:39:58
Hi,
 I have a question - this latest patch would be applicable to many different camera models, perhaps even most of them - is that right?

 I remember reading on here that all these multicam setups start off nicely with 2 cameras, then at about 10 cameras they mostly work ok, and then when you have lots of cameras, they can cause quite a lot of headaches - could this semaphore fix perhaps mean that, by avoiding random crashes,  multicam setups become nicely scaleable from 2 to X cameras?

 If so, then that's a really big change,

thanks,
Andrew


This fix would apply to any CHDK ports that use either EXMEM or ARAM memory (or both).
if it's the cause of stability issues in other multicam projects then, yes, it might improve things.


I'm still testing the code changes, hopefully I will put this in the autobuild for all camera over the weekend.


Phil.

Logged
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)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline srsa_4c

  • ******
  • 4451
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #57 on: 12 / October / 2017, 17:31:14 »
Quote from: philmoz on 08 / October / 2017, 06:28:58
if it fails a DebugAssert will be thrown.
There is a slight issue with the firmware's DebugAssert function.
The prototype currently used in platform/generic/wrappers.c does not cover the earliest and newest cameras.
Their DebugAssert has 3 arguments, so the correct prototype would be something like
extern void _DebugAssert(char *comment, char *src_file, int line);
Affected cameras are:
- Ixus30/40
- 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.
Logged
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #58 on: 12 / October / 2017, 17:53:03 »
Quote from: srsa_4c on 12 / October / 2017, 17:31:14
Since 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? 
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: suba threading bug (was Re: 3D scanner with multiple IXUS160 cameras)
« Reply #59 on: 12 / October / 2017, 19:31:30 »
Quote from: srsa_4c on 12 / October / 2017, 17:31:14
Quote from: philmoz on 08 / October / 2017, 06:28:58
if it fails a DebugAssert will be thrown.
There is a slight issue with the firmware's DebugAssert function.
The prototype currently used in platform/generic/wrappers.c does not cover the earliest and newest cameras.
Their DebugAssert has 3 arguments, so the correct prototype would be something like
extern void _DebugAssert(char *comment, char *src_file, int line);
Affected cameras are:
- Ixus30/40
- 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.


Sigh - nothing is ever easy.


I'll add the semaphore protection to suba with the safety checks disabled for now.
Once there is a solution for DebugAssert the checks can be enabled.


Phil.
Logged
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)
  g7x2 (1.01a, 1.01b, 1.10b)
Pages: 1 2 3 4 5 [6] 7 8   Go Up
« previous next »
 

Related Topics