supplierdeeply

experimental alternate memory allocation

  • 128 Replies
  • 15227 Views
Re: experimental alternate memory allocation
« Reply #60 on: 31 / January / 2011, 15:03:46 »
Advertisements
With Exmem enabled and 4MB allocated and 2MB not used, the menu characters are trash (but no crashes).
With Exmem enabled and 8MB allocated and 4MB not used, everything seems to work   :)


David

*

Offline reyalp

  • ******
  • 10055
Re: experimental alternate memory allocation
« Reply #61 on: 31 / January / 2011, 16:56:00 »
With Exmem enabled and 4MB allocated and 2MB not used, the menu characters are trash (but no crashes).
With Exmem enabled and 8MB allocated and 4MB not used, everything seems to work   :)
I would call this gambling. Not that there's anything wrong with that ;)
Don't forget what the H stands for.

Re: experimental alternate memory allocation
« Reply #62 on: 01 / February / 2011, 03:59:47 »
 >{
>                    _free(p);
>                         p=(void *)0;
>                        }

I think we should find the instruction that crash, when you set a value to 0 and it work then, this remember me on the wrong autogen stub entry for strcat.it use strncpy.

and this function use 1 parameter more and work diffrent.so it happen that this parameter get a random len value which only for log message output not good.

if this set to 0 help always is not clear, there can crash happen maybe on larger dir or so.

I have currently not much time to do.
so my hot guess is, that there is a function that have wrong stub and this is now show, because malloc now do inside func use more stack and registers.so the stack values and register are diffrent than before

My guess is this function sit after a malloc and is not often used in other chdk code, and it have on the autostub guess a a % value below 80%.

exmem really work stable what i do, i use it often and i like to photograph.
only problem is the filebrowser.and this problem happen too when no exmem is need.

I think it is best when exmem give us more memory, that we use for all string functions C code and no Canon functions, this avoid problems on newer Cams that autodetect stub code do wrong, at least with strcat

I see in all new firmware its wrong detect, but some have silenty correct it and not information other.

too bad that nobody other as me add in this thread Porting Problems and solutions, what find on wrong detect functions, or other porting Problems and fixes need on newer Camera.

http://chdk.setepontos.com/index.php?topic=6037.0

there are 125 reads now,but nobody write what problem he get and fix.
sure it cost a little time to write, but all in all porting go lots faster, if not everybody need Reinventing the wheel ;-)
« Last Edit: 01 / February / 2011, 04:10:49 by Bernd R »
Ixus 1000 HS

Re: experimental alternate memory allocation
« Reply #63 on: 02 / February / 2011, 06:29:54 »

exmem really work stable what i do, i use it often and i like to photograph.
only problem is the filebrowser.and this problem happen too when no exmem is need.

I do not understand, have you initialised the pointer ?  :-

static  void *exmem_heap=(void *)0;

Originally, strrchr() address was incorrect on S95.

It found first occurence of '\' instead of last.

Quote
there are 125 reads now,but nobody write what problem he get and fix.

Done.
« Last Edit: 02 / February / 2011, 06:37:58 by Microfunguy »


Re: experimental alternate memory allocation
« Reply #64 on: 02 / February / 2011, 06:42:51 »

exmem really work stable what i do, i use it often and i like to photograph.
only problem is the filebrowser.and this problem happen too when no exmem is need.

I do not understand, have you initialised the pointer ?  :-

static  void *exmem_heap=(void *)0;


I think this is not need, when do static ... var, the value is always set to 0.same as a global var.only local vars are not set to 0, because they use the stack.

and because exmem_heap have 0 , when remove the exmem init, old memroutines should use.

thanks for hint with strrchr, i verify on IX1000 and look for newest S95 source of 100E.
but there must be another problematic function somewhere in filebrowser code

EDIT:

I see that S95 Port use a own func in generic/wrappers.c.this and strcat maybe can add to main chdk with a ifdef FUNCS_IN_CHDKCODE or if you know a better name ?

Code: [Select]
char *strrchr(const char *s, int c) {
// waldo - unable to find strrchr in s95 FW - we use our own fn
    //return _strrchr(s, c);

char *result = 0;

c = (char) c;

do {
if (c == *s)
result = (char*) s;
} while (*s++ != '\0');

return result;
}
« Last Edit: 02 / February / 2011, 08:36:05 by Bernd R »
Ixus 1000 HS

Re: experimental alternate memory allocation
« Reply #65 on: 02 / February / 2011, 12:59:37 »
I think i find the Bug, its a buffer overflow in readdir.file generic/wrappers.c

Please use default code, with exmem init and increase the buffer size from 40 to 100.but maybe with less can work too.
Does it work on your Camera too ok and show more mem ?.

Code: [Select]
void* readdir(void *d) {
# if !CAM_DRYOS
    return _readdir(d);
#else
// for DRYOS cameras  A650, A720  do something with this!  - sizeof(de[]) must be >= sizeof(struct dirent): 'static char de[40];'
-   static char de[40];
+  static char de[100];
  _ReadFastDir(d, &de);
  return de[0]? &de : (void*)0;
#endif
}

Edit: the size of struct dirent seem 37 bytes, but its possible that there is some align gap in the structure.Its also possible that _ReadFastDir on new cameras have more entries now,

struct dirent {
    char                d_name[13];
    unsigned long   unk1;
    unsigned char    attrib;
    unsigned long    size;
    unsigned long   time1;
    unsigned long   time2;
    unsigned long   time3;
};
« Last Edit: 03 / February / 2011, 03:33:01 by Bernd R »
Ixus 1000 HS

Re: experimental alternate memory allocation
« Reply #66 on: 02 / February / 2011, 13:11:36 »
Not sure what you want me to prove because my version is working anyway (scripting and file browser) with Exmem.

Re: experimental alternate memory allocation
« Reply #67 on: 02 / February / 2011, 13:59:22 »
>Not sure what you want me to prove because my version is working anyway (scripting and file browser) >with Exmem.

yes it work, because you do strange workaround, but you can get trouble in something other place, or when later chdk code is change.

When new camera in

_ReadFastDir

store in the structure more than 40 bytes.so a more logical fix is increase the buffer and avoid problems.
readfastdir is used on more places
« Last Edit: 02 / February / 2011, 14:02:24 by Bernd R »
Ixus 1000 HS


Re: experimental alternate memory allocation
« Reply #68 on: 02 / February / 2011, 15:14:17 »

Please use default code, with exmem init and increase the buffer size from 40 to 100.

40 crashes the camera, 80 is fine.

I have not tested a lower value.


David

Re: experimental alternate memory allocation
« Reply #69 on: 04 / February / 2011, 09:27:15 »

Please use default code, with exmem init and increase the buffer size from 40 to 100.

40 crashes the camera, 80 is fine.

I have not tested a lower value.


David

I think 80 is too ok, but somebody should check with SDXC Card what happen when use a SDXC Card.As i hear SDXC use new filesystem

http://en.wikipedia.org/wiki/ExFAT

SDXC allow files larger as 4 gb so size should be 64 bit now.I guess
also new camera store the Favourite markers somewhere in filesystem, so this can too additional entry in the struct for readfastdir

Also i think SDXC maybe have larger names possible as the 13 char of FAT.

Have a CHDK User a SDXC Card, if the filebrowser still work with this ?. or is it possible to format a SD Card with exFAT
« Last Edit: 04 / February / 2011, 09:37:32 by Bernd R »
Ixus 1000 HS

 

Related Topics