On Mon, 3 Mar 2008 15:54:25 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
decompile isnt broken more than it was :) but still. got a test case for you:
eet -d sample.edj edje_file out.txt
this should work and produce a text file dump of the contents much like
blah "xxxx" {
blah "....
...
}
in out.txt
:)
> On Sun, Mar 2, 2008 at 6:50 AM, The Rasterman Carsten Haitzler
> <[EMAIL PROTECTED]> wrote:
> > 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 :).
>
> Just attached a patch that will do the job for the moment. For now,
> it's just doing a strdup of each string, so they are safe when you use
> it (their is still some possibility for a race condition as it is
> possible to change the file between eet_open and eet_data_read). I
> don't know if it would be a good idea to malloc and memcpy all the
> dictionary, but at the end all string will be copied in memory anyway.
> So it's perhaps the fix for Windows.
>
> > 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.
>
> It was missing some code arount EET_T_INLINED_STRING, should work
> cleanly now with compression enable and the second patch.
>
> --
> Cedric BAIL
>
--
------------- 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
