On Mon, 5 Dec 2016 04:10:49 +0100 Vincent Torri <vincent.to...@gmail.com> said:
> i still don't know how to fix the problem... you need to know where the access is. using EINA_ERROR_ABORT=1 will at least work on window as get you a backtrace to it... the reasons are either an invalid object id or access an object across threads. > On Mon, Dec 5, 2016 at 3:04 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > > On Mon, 5 Dec 2016 09:53:51 +0900 Jean-Philippe André <j...@videolan.org> > > said: > > > >> On 4 December 2016 at 11:27, Carsten Haitzler <ras...@rasterman.com> wrote: > >> > >> > On Sat, 3 Dec 2016 20:25:46 -0200 Gustavo Sverzut Barbieri < > >> > barbi...@gmail.com> > >> > said: > >> > > >> > > On Sat, Dec 3, 2016 at 7:13 PM, Vincent Torri <vincent.to...@gmail.com> > >> > wrote: > >> > > > On Sat, Dec 3, 2016 at 7:44 PM, Gustavo Sverzut Barbieri > >> > > > <barbi...@gmail.com> wrote: > >> > > >> On Sat, Dec 3, 2016 at 1:57 PM, Vincent Torri < > >> > vincent.to...@gmail.com> > >> > > >> wrote: > >> > > >>> Hello > >> > > >>> > >> > > >>> I'm rewriting my multi-document viewer. I'm using EFL git, and i > >> > have > >> > > >>> that Eo error message : > >> > > >>> > >> > > >>> ERR<59568>:eo[T:3] lib/eo/eo.c:1663 efl_isa() Object 40007f56 is > >> > > >>> not > >> > a > >> > > >>> valid object in this context: object domain: 0, current domain: 2, > >> > > >>> local domain: 2, available domains: [ 1 2 ] > >> > > >>> > >> > > >>> does someone have an idea of the problem ? > >> > > >> > >> > > >> the new efl in git provides more context to that message since > >> > > >> yesterday, particularly if you use EO_LIFECYCLE_DEBUG=1 (envvar), > >> > > >> since I was so pissed with such nebulous messages :-D > >> > > > > >> > > > all the debug stuff does not work on Windows (it needs libunwind, or > >> > > > at least DWARF parsing to get the debug symbols), but i will test on > >> > > > Linux when I have time. > >> > > > > >> > > > i've also seen some preload stuff you mentioned, which does not work > >> > > > on Windows (it's a different method to do similar stuff) > >> > > > > >> > > >> usually the object is already dead or was never created... If you're > >> > > >> using threads (seems so due "[T:3]"), be aware that objects are > >> > > >> bound to the thread they were created and you need to "import" to > >> > > >> use, Raster sent some email to the list and I recall som tests in > >> > > >> the tree.... > >> > > > > >> > > > I indeed use an ecore_thread > >> > > > >> > > yes, reading the message again, not just the T:3 for the thread, but > >> > > also the "object domain: 0" (main thread) while "current domain: 2" > >> > > (secondary thread) would lead to a failure since raster added the > >> > > protection. > >> > > >> > see the message is NOT nebulous. its giving you details the object > >> > belongs to > >> > thread domain 0 but your current domain is 2. thus thread does not belong > >> > to > >> > the same thread domain that created the object. domain 1 is the shared > >> > domain > >> > so should you see object domain being 1 and it still isn't found that > >> > means there is no object there at all ion the shared table. > >> > > >> > the message is very explicit as to the core details of the issue. it's an > >> > invalid object as far as the thread accessing it is concerned. > >> > > >> > > If you want to use auto-locks, then get the shared domain with: > >> > > > >> > > efl_domain_current_push(EFL_ID_DOMAIN_SHARED); > >> > > my_obj = efl_add(...); > >> > > efl_domain_current_pop(); > >> > > >> > this isn't really an option UNLESS you created the class entirely > >> > inherited from base class. i.e. the object class doesn't otherwise use > >> > any other non-threadsafe data outside the object. > >> > > >> > > check eo_test_general.c and Eo.h, they can give you an idea of what > >> > > can you do... basically all objects are bound to one thread (domain), > >> > > main thread or shared. Their parent must be in the same domain. This > >> > > allows TLS of eoid stuff, avoiding locks and possibly avoiding > >> > > concurrency bugs. Just the shared domains have locks as it used to be > >> > > in the whole eo. > >> > > >> > yup. and even creating shared objects comes with limitations. the intent > >> > is for > >> > very specialized objects to become shared objects so multiple threads can > >> > chare > >> > them. the general idea is you will have very very very few shared > >> > objects, so > >> > then the global mutex surrounding all shared objects isn't really a big > >> > issue,but sometimes sharing an object is far easier and simpler than > >> > anything > >> > else, and you are not that concerned about contention and performance. > >> > most objects will be thread-local (and most efl objects will be > >> > main-loop local of > >> > course). > >> > > >> > but the error right now is very detailed and tells you exactly what it > >> > sees is > >> > probably going wrong in the lookup so you can figure out if its a > >> > cross-thread > >> > access problem OR that the object actually does not exist. be aware that > >> > mainloop domain is 0, and the default domain for ALL other threads is 2. > >> > that > >> > means create obj in one non-mainloop thread and access in another > >> > non-mainloop > >> > thread ... both objects will have domain 1 BUT will have separate TLS > >> > based local object tables so the same object may haver the same domain > >> > but not be accessible across tables (there is a small chance you could > >> > get a false-positive access, but given i now starts generation counts > >> > off at random > >> > values per thread, its highly unlikely to have the same object id AND > >> > generation count match). > >> > <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel> > >> > > >> > >> > >> Nah I totally agree with Vincent that the error message is cryptic. > > > > the message before was just "this is an invalid object". try figure out why > > from that message: > > > > ERR("obj_id %p is not a valid object. Maybe it has been freed or does not > > belong to your thread?", (void *)obj_id); > > > > was the object before. well the specific one was an extra error you added in > > eo_isa. the generic obj pointer is invalid message is: > > > > const char *type = "object"; > > if (obj_id & ((Eo_Id)1 << (REF_TAG_SHIFT - 1))) type = "class"; > > ERR("EOID %p is not a valid %s. " > > "EOID domain=%i, current_domain=%i, local_domain=%i. " > > "EOID generation=%lx, id=%lx, ref=%i, super=%i. " > > "Thread self=%lu. " > > "Available domains [%s %s %s %s]. " > > "Maybe it has been deleted or does not belong to your thread?", > > > > (void *)obj_id, > > type, > > (int)domain, > > (int)data->domain_stack[data->stack_top], > > (int)data->local_domain, > > (unsigned long)(obj_id & MASK_GENERATIONS), > > (unsigned long)(obj_id >> SHIFT_ENTRY_ID) & (MAX_ENTRY_ID | > > MAX_TABLE_ID | MAX_MID_TABLE_ID), > > (int)(obj_id >> REF_TAG_SHIFT) & 0x1, > > (int)(obj_id >> SUPER_TAG_SHIFT) & 0x1, > > (unsigned long)eina_thread_self(), > > (data->tables[0]) ? "0" : " ", > > (data->tables[1]) ? "1" : " ", > > (data->tables[2]) ? "2" : " ", > > (data->tables[3]) ? "3" : " " > > ); > > > > maybe it should use the generic error print? > > > >> Anyway as far as I remember shared objects are not a viable solution until > >> we change the calling mechanism (function & data resolution) to be > >> thread-safe, rather than locking the entire pool of shared objects for the > >> entire duration of a call. > > > > locking the whole pool means we can do shared objects without a whole tonne > > of extra work. as long as all things accessed inside object methods > > (including parent classes) are entirely within the code for that object or > > are already threadsafe then no extra locks have to be written at all. > > everything will just work and it's a massive amount of work saved. having > > to fine-grain lock everything manually is just insane and that's why efl is > > not threadsafe and never will be because no one is going to go do that. > > this is why many libs are not threadsafe. it's a massive amount of work to > > do and easy to get wrong to miss an lock or unlock somewhere. having a > > single locking and unlocking spot even if it is a "one big fat lock for > > every shared object" is safer and far less work. it is unlikely to ever be > > a real performance issue. > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
