On Fri, 27 May 2005 00:12:55 +0200 "Eduard Feicho" <[EMAIL PROTECTED]> babbled:
> 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.
hmm
i think i knwo what it is
fnmatch in bsd has "" match "" glob
but linux's doesnt
will fix
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多 [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
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
