#16 os4 native filetype.module start crashes (tested on commit #606)

[kas1e]

Currently all what i can say, is that if we builds fully os4 version of svn606 (include filetype.module) , and then go and dbl-click on any unknown file, it will says "file unknown", and when we will press "create", then all crashes with such crashlog:

Stack trace:
(0x645F8D20) native kernel module kernel+0x000200a0
(0x645F8D50) native kernel module kernel+0x0002012c
(0x645F8D70) strdup()+0x2c (section 1 @ 0x8004)
(0x645F8D90) [filetype.c:2013] creator_display_info()+0x43c (section 1 @ 0x3E28)
(0x645F8E10) [filetype.c:2744] creator_generic()+0x2b4 (section 1 @ 0x5570)
(0x645F8E60) [filetype.c:663] finder_creator_proc_code()+0x244 (section 1 @ 0x5B64)
(0x645F8F90) native kernel module dos.library.kmod+0x00024ab4
(0x645F8FC0) native kernel module kernel+0x0006aa5c
(0x645F8FD0) native kernel module kernel+0x0006aadc

DAR are 0x00000000, which mean NULL pointer access

[kas1e]

Ok, it seems some general problem with malloc/free/strdup and not only for morphos. I.e. for now we have:

#ifdef __MORPHOS__
malloc want libnix_mempool on morphos, which are from libnix, and we can't use libnix together with --nostartup option which need it for libraries (which our plugins are)
void * malloc(size_t size) { return AllocVec(size, MEMF_ANY); }
void free(void *ptr) { return FreeVec(ptr); }
// also do own strdup, because it's dangerous to just freevec memory allocated by strdup
char *strdup (const char *orig) { char *copy = AllocVec(strlen(orig)+1, MEMF_ANY); if (copy) CopyMem(orig, copy, strlen(orig)+1); return copy;}
#endif

That one is crashes. Once we remove #ifdef MORPHOS (so replace code go and for os4 too), os4 version also start to works.

So, my bet we need to uncomment it for all oses.

[kas1e]

Ok ,i just un-comment it for all oses and add necessary comment at to.