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

Reply via email to