Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> schrieb am 25.05.05
07:48:40:
>
> On Wed, 25 May 2005 01:01:12 +0200 "Eduard Feicho" <[EMAIL PROTECTED]>
> babbled:
>
> > Hello,
> > I have been running e17 on NetBSD for a while now, but
> > after updating I get weird messages from it:
> >
> > DYNAMIC DETERMINED PREFIX: /usr/home/eddy/local
> > Xlib: extension "XpExtension" missing on display ":1.0".
> > Xlib: extension "XINERAMA" missing on display ":1.0".
> > E17 INIT: XINERAMA CHOSEN: [0], 1024x768+0+0
> > Xlib: extension "XpExtension" missing on display ":1.0".
> > Xlib: extension "XpExtension" missing on display ":1.0".
> > Xlib: extension "XpExtension" missing on display ":1.0".
> > ##- NEW CLIENT 0x40003e
> > ##- ON MAP CLIENT 0x40003e SIZE 504x343
> > ##- FIRST MAP
> > EDJE ERROR: programs recursing up to recursion limit of 64. Disabled.
> > SAVE!!!!
> > name: Eterm 0.9.4, class: Eterm
> > ##- SIZE HINTS for 0x40003e: min 30x44, max 32767x32767, base 24x31, step
> > 6x13
> > ##- NEW CLIENT SETUP 0x40003e
> > ##- REMANAGE!
> > ##- BORDER NEEDS POS/SIZE CHANGE 0x40003e
> >
> > I tried to further track down the problem by making various
> > builds of enlightenment based on the daily changes. So the
> > last version that worked here was from 2005-05-19.
> > The changes that may have gotten e out of order could be in:
>
> that shouldnt really happen. doesnt happen here. the recursion warning is
> when a
> program starts another program.. that starts another program. edje limits this
> chain to 64 levels. if it gets there it aborts the rest of the chain.
> interesting that it happens to you and not here. it shouldnt...
>
> well you have C for conflicts there - you have been modifying things locally
> and
> they conflict with upstream patches. you will have to results the conflicts
> by
> hand as it wont build for you... :( or just nuke it all and check out a new
> tree.
>
Well the output was what cvs gave me when updating from sources dated
2005-05-19 to 2005-05-20, since those from 2005-05-20 have obviously
introduced the problem. Though there are no changes that concern edje.
Anyways I hspent some more time with it and found out that
the problem should have something to do with loading
$PREFIX/share/enlightenment/data/init.edj, which
causes edje to hang up. It repeats to run the Edje_Program with the
name logo_animate4 forever. I have added debugging info
in _edje_program_run(...) in e17/libs/edje/src/lib/edje_program.c, which
outputs.
edje_program_run: Edje_Program pr: init_pause (80B7F00)
edje_program_run: Edje_Program pr: logo_show (80B7F80)
edje_program_run: Edje_Program pr: logo_animate (80D4000)
edje_program_run: Edje_Program pr: logo_animate2 (80D4080)
edje_program_run: Edje_Program pr: logo_animate3 (80D4100)
edje_program_run: Edje_Program pr: logo_animate4 (80D4180)
edje_program_run: Edje_Program pr: logo_animate4 (80D4180)
edje_program_run: Edje_Program pr: logo_animate4 (80D4180)
[ - snip - ]
(The names correspond to pr->name)
Given may be the backtrace
#0 _edje_program_run (ed=0x8099e00, pr=0x80d4100, force=0,
ssig=0x480ccb80 "", ssrc=0x480ccb80 "") at edje_program.c:422
#1 0x480c0e84 in _edje_program_run (ed=0x8099e00, pr=0x80d4080, force=0,
ssig=0x480ccb80 "", ssrc=0x480ccb80 "") at edje_program.c:557
#2 0x480c0e84 in _edje_program_run (ed=0x8099e00, pr=0x80d4000, force=0,
ssig=0x480ccb80 "", ssrc=0x480ccb80 "") at edje_program.c:557
#3 0x480c0e84 in _edje_program_run (ed=0x8099e00, pr=0x80b7f00, force=0,
ssig=0x83050c0 "show", ssrc=0x83050d0 "") at edje_program.c:557
#4 0x480c1b3e in _edje_emit_handle (ed=0x8099e00, sig=0x83050c0 "show",
src=0x83050d0 "") at edje_program.c:838
#5 0x480cb2ac in _edje_message_process (em=0x82efd20)
at edje_message_queue.c:433
#6 0x480cb7f4 in _edje_message_queue_process () at edje_message_queue.c:598
#7 0x480caa8c in _edje_job (data=0x0) at edje_message_queue.c:99
#8 0x48117ab6 in _ecore_job_event_handler (data=0x0, type=69, ev=0x8305040)
at ecore_job.c:75
#9 0x488401e8 in _ecore_event_call () at ecore_events.c:397
#10 0x488450b1 in _ecore_main_loop_iterate_internal (once_only=0)
at ecore_main.c:629
#11 0x48844227 in ecore_main_loop_begin () at ecore_main.c:79
#12 0x08056391 in main (argc=3, argv=0xbfbffba0) at e_main.c:450
#13 0x080551f2 in ___start ()
so that you can find the loop which calls this code,
which begins from line 529 in e17/libs/edje/src/lib/edje_program.c:
for (l = pr->after; l; l = l->next)
{
Edje_Program *pr2;
Edje_Program_After *pa = l->data;
if (pa->id >= 0)
{
pr2 = ed->table_programs[pa->id %
ed->table_programs_size];
if (pr2) _edje_program_run(ed, pr2, 0, "", "");
if (_edje_block_break(ed)) goto break_prog;
}
}
_edje_recalc(ed);
The contents of ed->table_programs are shown below:
(gdb) p ed->table_programs[0]->name
$15 = 0x80d0820 "init_pause"
(gdb) p ed->table_programs[1]->name
$16 = 0x80d08b0 "logo_show"
(gdb) p ed->table_programs[2]->name
$17 = 0x80d0910 "logo_animate"
(gdb) p ed->table_programs[3]->name
$18 = 0x80d0980 "logo_animate2"
(gdb) p ed->table_programs[4]->name
$19 = 0x80d09f0 "logo_animate3"
(gdb) p ed->table_programs[5]->name
$20 = 0x80d0a60 "logo_animate4"
My first thought was that the index of each program would not
be calculated correctly, but since all programs are called
in the right order this idea is probably not the case.
In my opinion the loop should end with pr->after being NULL
(someone would have to acknowledge this), which
is not the case for pr->name being "logo_animate4".
The question is what pr->after points to at last.
Some debugging shows that the list, that after represents,
is not the same list as logo_animate3's after-member:
When at pr->name is logo_animate3, pr->after is
(Evas_List *) 0x80d29e0
When pr->name is logo_animate4 pr->after is
(Evas_List *) 0x80d2a40
Obviously two different lists.
The Lists that themself contain the adress of the next
Edje_Program_After in the member data look like:
logo_animate3: {data = 0x80d0a50, next = 0x0, prev = 0x0, last = 0x80d29e0,
count = 1}
logo_animate4: {data = 0x80d0ac0, next = 0x0, prev = 0x0, last = 0x80d2a40,
count = 1}
As you can see data is not the same, so what about data?
Casting data to an Edje_Program_After pointer results in the
two Edje_Program_After structs, whose member id is 5. And
because this member will always be 5,
[5 % ed->table_programs_size] in line 538 will result in 5 again
and there you have an endless loop.
It seems as if Edje_load or something similar put one List too much
into the Edje. That of course might be becaue of some portability issue
concerning my NetBSD. I will try to find out what it is, but help is
appreciated. It would be nice if you could give comments like
where I can find the place where the init.edj is loaded, so that
I can take a look why after is not NULL. I will search for it in the
meantime. Or maybe you have a different opinion on what the reason
for this behaviour could be.
So far - have a goodbye
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
