On Thu, 15 Dec 2011 11:05:47 +0900 Jaehwan Kim <jaehwan.kim....@gmail.com> said:
you still have bugs. try 64bit x86 so it actually crashes. i yet again get crashes on running edje_cc in my builds with your patch: ==29174== Conditional jump or move depends on uninitialised value(s) ==29174== at 0x40E0ED: mem_realloc (edje_cc_mem.c:34) ==29174== by 0x40E3DB: _edje_part_description_alloc (edje_cc_handlers.c:844) ==29174== by 0x413CED: ob_collections_group_parts_part_description (edje_cc_handlers.c:4152) ==29174== by 0x40A5DE: new_object (edje_cc_parse.c:137) ==29174== by 0x40B74D: parse (edje_cc_parse.c:555) ==29174== by 0x40C023: compile (edje_cc_parse.c:782) ==29174== by 0x404ABC: main (edje_cc.c:235) ==29174== Uninitialised value was created by a stack allocation ==29174== at 0x413C94: ob_collections_group_parts_part_description (edje_cc_handlers.c:4144) ==29174== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n ==29174== Conditional jump or move depends on uninitialised value(s) ==29174== at 0x4C2901D: realloc (vg_replace_malloc.c:525) ==29174== by 0x40E118: mem_realloc (edje_cc_mem.c:37) ==29174== by 0x40E3DB: _edje_part_description_alloc (edje_cc_handlers.c:844) ==29174== by 0x413CED: ob_collections_group_parts_part_description (edje_cc_handlers.c:4152) ==29174== by 0x40A5DE: new_object (edje_cc_parse.c:137) ==29174== by 0x40B74D: parse (edje_cc_parse.c:555) ==29174== by 0x40C023: compile (edje_cc_parse.c:782) ==29174== by 0x404ABC: main (edje_cc.c:235) ==29174== Uninitialised value was created by a stack allocation ==29174== at 0x413C94: ob_collections_group_parts_part_description (edje_cc_handlers.c:4144) ==29174== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n ==29174== Invalid free() / delete / delete[] ==29174== at 0x4C290A4: realloc (vg_replace_malloc.c:525) ==29174== by 0x40E118: mem_realloc (edje_cc_mem.c:37) ==29174== by 0x40E3DB: _edje_part_description_alloc (edje_cc_handlers.c:844) ==29174== by 0x413CED: ob_collections_group_parts_part_description (edje_cc_handlers.c:4152) ==29174== by 0x40A5DE: new_object (edje_cc_parse.c:137) ==29174== by 0x40B74D: parse (edje_cc_parse.c:555) ==29174== by 0x40C023: compile (edje_cc_parse.c:782) ==29174== by 0x404ABC: main (edje_cc.c:235) ==29174== Address 0x2905cda1bc is not stack'd, malloc'd or (recently) free'd these end up with a crash. > Dear Anyone concerned group inherit > > I changed the part of type-change in group inherit. > Lately, raster removed the code about the prohibition of type-change in > group inherit. > But about the "part" of different type, the data structure of the their > "description" is different. > So if the type is changed, it have to be reallocated. Current, it is not. > > At first, we have to remove the lookups. If we don't, when lookup module > executes, the memory > may be broken. So I removed all lookups for reallocated description before > it is reallocated. > And I changed all description of the "part" is reallocated when the type is > changed. > The attribute of the "part" is remained. Just it reallocated the part of > **_Spec_**. > > Even if there is no problem currently, this change is necessary. > Please review my patch. > If it is proper, I will upload it in the svn. > > Thanks. > -- > Jaehwan Kim. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
