On Thu, 17 Jan 2013 03:52:36 -0500 (EST) [email protected] said:
> > > Hi all, > I am getting the below error, and what makes "_ecore_magic_fail()" to fail > and what is "sf_connect". > ERR<1580>:ecore ecore.c:480 _ecore_magic_fail() > *** ECORE ERROR: Ecore Magic Check Failed!!! > *** IN FUNCTION: ecore_timer_interval_set() > ERR<1580>:ecore ecore.c:484 _ecore_magic_fail() Input handle has already > been freed! ERR<1580>:ecore ecore.c:493 _ecore_magic_fail() *** NAUGHTY > PROGRAMMER!!! *** SPANK SPANK SPANK!!! > *** Now go fix your code. Tut tut tut! > debug level init 1(1) > appcore: sf_connect failed: -1 "magic" is short for magic number checking. when you pass pointers (to objects) to efl - a lot/most api's check things called "magic numbers (or signatures) that act as type info as well as sanity checks (on deletion of such an object the magic number will be set to 0 or some known pattern). this tells you a few things (possibly): 1. you passed in a valid handle to an ecore object - it's all fine BUT someone has corrupted memory and scribbled at least over the object header making the magic number not match. 2. most likely - the pointer points to valid memory you can access BUT it has been freed and either is now unused or has been recycled for other purposes. 3. you provided a valid pointer to a valid object... but its an object of the wrong type (magics wont match then either). if the pointer pointed out of accessible memory space you'd get a segfault instead. you can trap these as ecore will abort() when it detects this with and use gdb to get a nice backtrace: export ECORE_ERROR_ABORT=1 tho i suspect your ecore is older so i'd need to check previous releases but i think that was there long before (the abort logic) -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ General mailing list [email protected] https://lists.tizen.org/listinfo/general
