new branch - CHDK : Elf Edition - Developers wanted - page 19 - General Discussion and Assistance - CHDK Forum supplierdeeply

new branch - CHDK : Elf Edition - Developers wanted

  • 316 Replies
  • 99264 Views
*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #180 on: 05 / January / 2012, 19:14:59 »
Advertisements
Forgive me, I always post which camera do I have and this time I forgot.

SX130IS
Firmware 1.01c

I use CHDK trunk #1527

Yes, it's defined:
#define   CAM_STARTUP_CRASH_FILE_OPEN_FIX   1

I don't remember, wheter not modular CHDK caused such crash, maybe I never noticed that. But now it's everytime I go to the menu too fast (CHDK teaches me patience now!).

EDIT

PS - I saw this thread: http://chdk.setepontos.com/index.php?topic=265.0 - should I post such things there rather? I don't like to make a mess in forum.

Can you zip up and post the core/main.dump file from the build that crashed (needs to match the romlog file).

This is probably the best place to post for now since it's specific to the module system (and not in the autobuild release version).

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

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #181 on: 05 / January / 2012, 19:48:05 »
Ok, here it is. I had to recompile the source to avoid cleaning core. But it was from the same, unchanged source as previous log.
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #182 on: 05 / January / 2012, 20:44:32 »
Ok, here it is. I had to recompile the source to avoid cleaning core. But it was from the same, unchanged source as previous log.

Thanks, an initial look would seem it is crashing in 'opendir'; but with the same 'fsionotify' type problem as we had with 'open'.

I'll examine the 'opendir' function in the firmware later tonight to see if there is a workaround like we used for 'open'.

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

*

Offline reyalp

  • ******
  • 13729
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #183 on: 05 / January / 2012, 23:13:49 »
Ok, here it is. I had to recompile the source to avoid cleaning core. But it was from the same, unchanged source as previous log.

Thanks, an initial look would seem it is crashing in 'opendir'; but with the same 'fsionotify' type problem as we had with 'open'.

I'll examine the 'opendir' function in the firmware later tonight to see if there is a workaround like we used for 'open'.
I've noticed intermittent "ASSERT!! FsIoNotify.c Line 451" startup crashes on D10 with the module build, even with strartup crash fix enabled.

opendir uses Open under the hood. :(
Don't forget what the H stands for.


*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #184 on: 05 / January / 2012, 23:48:37 »
Ok, here it is. I had to recompile the source to avoid cleaning core. But it was from the same, unchanged source as previous log.

Thanks, an initial look would seem it is crashing in 'opendir'; but with the same 'fsionotify' type problem as we had with 'open'.

I'll examine the 'opendir' function in the firmware later tonight to see if there is a workaround like we used for 'open'.
I've noticed intermittent "ASSERT!! FsIoNotify.c Line 451" startup crashes on D10 with the module build, even with strartup crash fix enabled.

opendir uses Open under the hood. :(

Which effectively rules out having the 'Modules' menu built dynamically at startup by processing all the .flt files in the CHDK/Modules directory. Unless a reliable fix can be found for this.

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

*

Offline reyalp

  • ******
  • 13729
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #185 on: 06 / January / 2012, 00:09:46 »
Which effectively rules out having the 'Modules' menu built dynamically at startup by processing all the .flt files in the CHDK/Modules directory. Unless a reliable fix can be found for this.
Might be better to populate it on open, keeping startup time down would be good anyway. A little delay in the menu coming up should tolerable, especially if it's just the first time.

Another approach would be to add the variable that tracks how many slots are available to the sig finder, and make a function that sleeps until there are sufficient slots available. If you can do what you need to do without yielding, the canon firmware shouldn't come along and hit the same assert.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #186 on: 06 / January / 2012, 00:39:50 »
Might be better to populate it on open, keeping startup time down would be good anyway. A little delay in the menu coming up should tolerable, especially if it's just the first time.

That's what the current code does; but from the reports it is not reliable if the menu is entered too quickly.

Quote
Another approach would be to add the variable that tracks how many slots are available to the sig finder, and make a function that sleeps until there are sufficient slots available. If you can do what you need to do without yielding, the canon firmware shouldn't come along and hit the same assert.

The problem isn't running out of space in the fsionotify table, it's calling 'Open' and getting a file handle that still exists in the table because another 'Close' call hasn't finished cleaning up. If there isn't an alternative to 'opendir' in the firmware that we can use (i.e. open V Open) then we would have to copy and modify the code for 'opendir' into CHDK - for all cameras.

I still think going back to static menus is the least problematic solution.

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

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #187 on: 06 / January / 2012, 06:27:26 »
Based on your information I make some experiments.
I found how to fix problem on my S95. But have no idea why it works. :)

Test enviroment #1 - just right as it was now. It always crash if try to popup menu first time while led blinking right after shoot with built-in RAW.
Test enviroment #2 - move gui_module_menu_load() back to gui_init() to crash on startup but avoid influence of how my finger speed.

Max valuable depth of MODULE dir is I:\CHDK\MODULES\GAMES\NEW\DEEP\TEST\ depth (depth could have matter because currently module_menu recursively open each of this dir without closing previous. Probably this should be rewrited, this probably increasy slightly memory fragmentation but decrease risk to exhaust resources).

Results:
Enviroment #1 - crash always before, crash never after
Enviroment #2 - crash with 80% chance with my current SD content, crash never after fix.

How did I fix.
Code below is added in the begining of safe_opendir(). This function is only valid way to use opendir inside module. So this will work for all other modules too.
Code: [Select]
int fd = open(name, O_RDONLY, 0777);
if ( fd <= 0 )
return 0;
close(fd);

UPD: forget to say. Module menu successfully resolve modules in path above. So looks like this fix not just return fail but wait until resources become available.
« Last Edit: 06 / January / 2012, 06:35:03 by tsvstar »


*

Offline philmoz

  • *****
  • 3411
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #188 on: 06 / January / 2012, 07:09:07 »
Based on your information I make some experiments.
I found how to fix problem on my S95. But have no idea why it works. :)

Test enviroment #1 - just right as it was now. It always crash if try to popup menu first time while led blinking right after shoot with built-in RAW.
Test enviroment #2 - move gui_module_menu_load() back to gui_init() to crash on startup but avoid influence of how my finger speed.

Max valuable depth of MODULE dir is I:\CHDK\MODULES\GAMES\NEW\DEEP\TEST\ depth (depth could have matter because currently module_menu recursively open each of this dir without closing previous. Probably this should be rewrited, this probably increasy slightly memory fragmentation but decrease risk to exhaust resources).

Results:
Enviroment #1 - crash always before, crash never after
Enviroment #2 - crash with 80% chance with my current SD content, crash never after fix.

How did I fix.
Code below is added in the begining of safe_opendir(). This function is only valid way to use opendir inside module. So this will work for all other modules too.
Code: [Select]
int fd = open(name, O_RDONLY, 0777);
if ( fd <= 0 )
return 0;
close(fd);

UPD: forget to say. Module menu successfully resolve modules in path above. So looks like this fix not just return fail but wait until resources become available.

Your 'fix' is only masking the problem by changing the timing.
As discussed in this thread http://chdk.setepontos.com/index.php?topic=6179.0, the problem happens when CHDK and the Canon firmware are both opening and closing files at the same time.

The 'Open' function adds the file handle to an array after the file is opened. The 'Close' function removes the file handle after the file is closed. But there is no multi-tasking protection around these functions.

If the Canon firmware is closing a file and CHDK opens a new file before 'Close' has removed the handle from the array then CHDK can get back the same file handle just closed. The call to 'Open' from CHDK asserts because it finds the file handle already in the array.

The current fix is to use the 'open' firmware function instead of 'Open' - this function does not add the file handle to the array. As reyalp has pointed out 'opendir' calls 'Open' internally so the CHDK hack won't help here.

So your fix might work at the moment on your camera; but there is no guarantee it will work on any others, or that it will always work on yours. For example, the number of images on the card affects the startup timing and thus the chance of the problem occurring.

The other issue that needs clarification is the 32 character path length limit on some cameras.
This limit means that you cannot open a file or directory where the path name + file name is more than 32 characters. So for example A/CHDK/MODULES/mastmind.flt will work (27 chars); but A/CHDK/MODULES/GAMES/mastmind.flt will fail (33 chars).

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

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #189 on: 06 / January / 2012, 08:32:10 »
Your 'fix' is only masking the problem by changing the timing.
Probably you are right. Adding msleep(1) to same place also fix problem.
I just surprised that few millisecond turn always crash to always work for several seconds interval (built-in raw write duration).

Quote
As discussed in this thread http://chdk.setepontos.com/index.php?topic=6179.0, the problem happens when CHDK and the Canon firmware are both opening and closing files at the same time.
Yes I readed thread. And yes I really do not know why this fix problem so stable.

Quote
So your fix might work at the moment on your camera; but there is no guarantee it will work on any others, or that it will always work on yours. For example, the number of images on the card affects the startup timing and thus the chance of the problem occurring.

We could check this. :)
Fillup card with ~1300 jpeg (no more space). Startup time >60 sec. Never crash with fix, absolutely always crash without.
We could ask outslider does this fix help.

Unfortunatelly this fix have sideeffect: fileselector show nothing. Moving code inside mod_menu doesn't help. One more argument for "timing"

I also do not like magic in developing. And I have no idea why this make so stable but it does.

Quote
The other issue that needs clarification is the 32 character path length limit on some cameras.
This limit means that you cannot open a file or directory where the path name + file name is more than 32 characters. So for example A/CHDK/MODULES/mastmind.flt will work (27 chars); but A/CHDK/MODULES/GAMES/mastmind.flt will fail (33 chars).
Yes I know about this. Example path is just to make multiple opendir simultaneous by modmenu

PS - I have nothing against static menu. But I would like to have dynamic list too at least.

 

Related Topics