From: Vincent T. <vin...@gm...> - 2012-02-27 09:50:41
|
On Mon, Feb 27, 2012 at 3:42 AM, Carsten Haitzler <ra...@ra...> wrote: > On Mon, 27 Feb 2012 11:24:29 +0900 Kim Shinwoo <kim...@gm...> said: > >> Hey dear, please refer to the following information. >> >> Breakpoint 1, eet_string_match (s1=0x490ba5 <Address 0x490ba5 out of >> bounds>, s2=0x639db184 "edje/file") >> at eet_lib.c:334 >> 334 return !strcmp(s1, s2); >> (gdb) up >> #1 0x6fdc1e00 in find_node_by_name (name=0x639db184 "edje/file", ef=<value >> optimized out>) at eet_lib.c:2507 >> 2507 if (eet_string_match(efn->name, name)) >> (gdb) print efn->name_size >> $3 = 10 >> (gdb) print efn->name >> $4 = 0x490ba5 <Address 0x490ba5 out of bounds> >> (gdb) >> >> Anyhow, I cannot make corefile on MinGW... If you need any other >> information, please tell me. > > weird. size looks right, name ptr wrong. it's as if the file that was being > used has been munmapped/closed... the only weay we will find this is by finding > that close... but why would that be closed on windows and not also on linux as > its the same logic/codepath at that level - evil wraps the map stuff further > down the stack. is there a way you can print/track file mappings in windows? > (/proc/PID/maps style or the pmap tool?) implementation in eet use eina_file, iirc. The implementation on Windows is different than on linux. See eina_file.c and eina_file_win32.c. The code in eina_file_win32.c should be checked, i guess. about log, of course, that can be done. With some use DBG(). Vincent |