On Sun, 2 Mar 2008 02:43:48 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled:
> On Sun, Mar 2, 2008 at 12:48 AM, The Rasterman Carsten Haitzler > <[EMAIL PROTECTED]> wrote: > > On Fri, 15 Feb 2008 15:56:12 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> > > babbled: > > > > i found a wonderful nasty "bug"... > > > > 1. edje keeps the eet handle open. > > 2. edje uses the string dictionary > > 3. what happens if you delete the edj file edje is depending on and it then > > tries to make use of any o the strings from the dictionary... :) (hint: > > some signal around #11 :)). > > > > :) > > > > try this. use some theme X in e. have the source and recompile it (be nice > > - delete the original. recompiling the theme in-place is even worse as u > > screw with the file that eet has mmaped() in with string dictionary data): > > > > rm X.edj; edje_cc X.edc > > > > now go move your mouse around. move a window. bam. segv. :) > > this is the same thing for running binaries, but since it's a common > case you get an error and the binary can't be removed with a "file > busy". There is a correct procedure for doing such things that takes > reference counting from FS to make it behave. I don't have time to > search for it now, will do it tomorrow when I wake up. actualyl the bug was a refcount issue - it was literally deleting the eet handle before its time - its refcount got to 0 when it shouldnt have. thus the file descriptor was closed and thus we lost the dictionary contents. if we retained the file handle and the mmap we are fine as long as u delete the old .edj first then replace it as unix fs semantics will keep the open copy. of course win32 will break wonderfully :). and yes - replacing the .edj in-place is dangerous and will cause problems like this or even segv's now. before it was safe. i fixed this now, but we have other problems :) compression no longer works for eet data encoded sections as the eet data is decoded with pointers TO the data chunk it was decoded from, but if compressed this is freed as the data one decoded is expected t be stand-alone and not dependent on the original data lump it was decoded from. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
