Re: [E-devel] Recent troubles with evas
I had the same problem here and I noticed that there are 2 copies of the file Evas_Engine_Buffer.h in the source tree. After simply removing the one inside e17/libs/evas/src/lib/ it compiled without problems; Tiago ÐикÑÐ¾Ñ ÐожÑÑ Ð°Ñов wrote: I think today, evas broke, and couldn't be compiled. evas_engine.c: In function `evas_engine_buffer_output_setup': evas_engine.c:294: error: `EVAS_ENGINE_BUFFER_DEPTH_RGB32' undeclared (first use in this function) evas_engine.c:294: error: (Each undeclared identifier is reported only once evas_engine.c:294: error: for each function it appears in.) if you replace the undeclared macro with 4 (as its defined in the header), it compiles fine. however, now, a piece of code i'm working on, that worked yesterday, produces a weird segfault, with the following even weirder backtrace: 0xb7b7b400 in _append_text_run () from /opt/e17//lib/libevas.so.1 (gdb) bt #0 0xb7b7b400 in _append_text_run () from /opt/e17//lib/libevas.so.1 #1 0x0813c180 in ?? () #2 0x0813c000 in ?? () #3 0xbf8d8928 in ?? () #4 0xb7fa27b0 in _etk_editable_text_smart_add (object=0x8955c35d) at etk_editable_text_object.c:459 Previous frame inner to this frame (corrupt stack?) I dont even know where to start debugging with such a bt. on a similar note, the following file is present in the cvs, but it shouldn't be: src/lib/file/evas_module.lo --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ___ Yahoo! doce lar. Faça do Yahoo! sua homepage. http://br.yahoo.com/homepageset.html --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Segfault in __imlib_amd64_copy_rgb_to_rgba () Solved
Great.. and sorry for me not sending the patch, but as said I'm currently without my linux box at home and for work use only windows ... Perhaps someone should commit a patch in CVS to fix all of these cases (first it was in copy_rgba_to_rgba, now in copy_rgb_to_rgba but there are a few other functions that appear to have the same problem); I had such a small patch, just have to re-create it, will do it.. --- Ursprüngliche Nachricht --- Von: Ivan Hernandez [EMAIL PROTECTED] An: enlightenment-devel@lists.sourceforge.net Kopie: Tiago Victor Gehring [EMAIL PROTECTED] Betreff: Re: [E-devel] Segfault in __imlib_amd64_copy_rgb_to_rgba () Solved Datum: Tue, 8 Nov 2005 10:33:00 -0300 Tiago: Yes, your patch is right. i have replaced the movdqa at imlib2/src/lib/amd64_blend.S line 1267 with movdqu and it worked fine. the original source was... SIZE(imlib_amd64_copy_rgba_to_rgba) PR_(imlib_amd64_copy_rgb_to_rgba): ENTER movdqa mX000X000X000X000(%rip), %xmm5 leaq (%rsi, %r8, 4), %rsi leaq (%rdi, %r8, 4), %rdi and resulting source was: SIZE(imlib_amd64_copy_rgba_to_rgba) PR_(imlib_amd64_copy_rgb_to_rgba): ENTER movdqu mX000X000X000X000(%rip), %xmm5 leaq (%rsi, %r8, 4), %rsi leaq (%rdi, %r8, 4), %rdi It solved my problem and now emblem works fine. Thanks a lot! Ivan Hernandez (zaikxtox) El Dom 06 Nov 2005 21:10, Tiago Victor Gehring escribió: I had the same problem on my amd64 computer, the problem is the (assembly) amd64 optimized routines in imlib2; It's just a matter of replacing a couple of movdqa instructions (aligned mov) to movdqu (unaligned mov), there's practically no performance hit (I guess) because this instructions are outside the loops that actually copy the data; This has already been discussed and one patch for the case of the function ..._copy_rgba_to_rgba even committed (this was the one that originally gave me problems); I had a small patch for the other cases but have to re-create it because my amd64 notebook is being repaired and I'm only with a Winblows computer for work.. :-) Anyway, I'll try to do it (I mean re-create the patch) tomorrow ok, so you can test it and see if it works.. Tiago Gehring [EMAIL PROTECTED] wrote: I have yesterdey get a clean cvs version after trying the last e source on my office. On i686 it works fine, and a lot of changes and new thing were happening from the last update i did to now... but curiously, on amd64, i found myself unable to run emblem. It's not a pain for me because i can set up the background with enlightenment_remote, but doing a little more os investigation with gdb it says: ::[EMAIL PROTECTED] (08:29:45) - ~/Documentos/src/e17 }:: .oOo. gdb -e emblem GNU gdb 6.3-debian This GDB was configured as x86_64-linux. (gdb) run Starting program: /usr/local/bin/emblem Using host libthread_db library /lib/libthread_db.so.1. [Thread debugging using libthread_db enabled] [New Thread 182928639344 (LWP 15810)] Unable to load file, Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 182928639344 (LWP 15810)] 0x002a965c13fb in __imlib_amd64_copy_rgb_to_rgba () from /usr/local/lib/libImlib2.so.1 (gdb) i have imported the code as anjuta project (the only one ide i know how to debug correctly) and apparently the Unable to load file, has nothing to do with the bug. it comes a lot earlier. Also, i have dumped my enlightenment conf dir (mv .e .e.notusing) and it continued this way. I have downloaded again imlib2 from cvs, on a clean directory and compiled all again, libs, and e, and e_utils... but the bug is still there. Asking on #e @ freenode.net i have found that someone else has the same problem, on amd64, with another distribution. If someone knows how to get more information with gdb, and how to attach the source to de debugger so i can give more info it will be nice. Thanks for all Ivan Henrnandez (zaikxtox) --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
RE: [E-devel] 64 bit cleanliness Imlib2 funckyness (patch)
Like I said last time I also had problems with AMD64 imlib2 (noticed that using also feh image viewer); For me the problem is just some mov instructions that asume that the memory is aligned, after changing a couple of movdqa to movdqu all worked fine (including the menus in feh); I originally sent a patch for just one of the optimized blend functions, but later I sent another one for the other functions (some 10 lines or so) - this wasn't commited I guess. It was already noted also that the performance impact of this change is minimal because there at most only 3 mov calls for each blend_** call that where changed (ie, the changed mov calls are not inside any loop); Anyway, I don't know, as said for me feh is working great (menus also) now and I saw that the patch you sent is quite different. I'll try (later) to get imlib2 from CVS again and try it out with feh, maybe something has changed that broke it again on amd64... Tiago -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tres Melton Sent: Wednesday, September 28, 2005 11:55 AM To: Mike Frysinger Cc: Enlightenment/Eterm Developers List Subject: [E-devel] 64 bit cleanliness Imlib2 funckyness (patch) vapier sent me on a mission to find out why imlib2's, newly enabled for the amd64, code seg-faults on his machine. I can confirm that it crashes on mine too. I found a chunk of code that assumes 32 bit pointers and this patch corrects that behavior. Anyway the program feh crashes when you try to open a menu with the mouse and it has been traced to the --enable-amd64 configure option. My current system (CVS is current) configuration is: --- - imlib2 1.2.1.006 --- - Configuration Options Summary: Image Loaders: JPEG: yes PNG.: yes TIFF: yes GIF.: yes ZLIB: yes BZIP2...: no ID3.: yes Use MMX for extra speed...: no Use AMD64 for extra speed.: yes Installation Path.: /usr Compilation...: make Installation..: make install --- - Sorry Mike, the bug seems to be deeper than just this. Cheers, -- Tres Melton IRC Gentoo: RiverRat ___ Novo Yahoo! Messenger com voz: ligações, Yahoo! Avatars, novos emoticons e muito mais. Instale agora! www.yahoo.com.br/messenger/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch - imlib2 blend in AMD64
Sorry for the delay in the response.. Well, I tested it again and really, just putting the alignment in the .text segment didn't work. I then changed all the remaining movdqa (only the %rip ones sure), because I'm almost sure that they would also give problems. The change involved at most 3 instructions per call, so the performance impact as you noted should be totally negligible. The patch is attached, if someone could please put it in CVS I think that the matter is closed then. Thanks, and thanks also for the info about up relative addressing, Tiago On Thu, 2005-08-25 at 03:33 -0600, John Slaten wrote: Hmmm. That should have worked. Basically, what ip relative addressing does is make the code position independent. When the assembler sees an instruction like that, it makes the offset (mX000X000X000X00) equal to the offset from the next instruction in the code to the specified data, so that no matter where the program is located in memory, the data can always be found right at the same spot. I don't know why forcing the alignment did not make the program work. I suppose that the only solution then is to change all of the (%rip) movdqa instructions to movdqu - if the changes are kept to the ip-relative ones, the performance impact should be minimal as these are only executed once per function call. On Thu, 2005-08-25 at 06:44 +, Tiago Victor Gehring wrote: Hi, thanks for the info and help - nothing like hearing from who wrote the code... I then applied your patch and put the original lines back, with the aligned copy, but I now get again the same problem as before, segmentation faults.. The first line that gives me problem is #570, this is a piece of the code so you can find it: LEAVE SIZE(imlib_amd64_blend_rgba_to_rgb) PR_(imlib_amd64_blend_rgba_to_rgba): ENTER pxor %xmm4, %xmm4 movdqa c1(%rip), %xmm5 - *** here's the first problem xorq %rax, %rax movdqa mX000X000X000X000(%rip), %xmm6 movq [EMAIL PROTECTED](%rip), %r13 And I confirmed that now I compiled it with the .align 16 in the .text segment.. And just being curious now, could you perhaps explain what does a instruction like the above does? I mean, what does the mask in front of the %rip does, you take the address of the next instruction, apply (AND) a mask and move it to %xmm5? Sorry, just curious... Thanks, Tiago On Wed, 2005-08-24 at 18:45 -0600, John Slaten wrote: Since I wrote the original code, I thought I'd weigh in on this. 1. The memory that is causing the errors is statically allocated data in the .text segment, which I assumed would be correctly aligned and forgot to supply the .align directive. Adding this (as in the attached patch) _should_ fix the problem, though I have not tried to reproduce/test it. The code should then work with the aligned instructions as in the original. 2. The existing code jumps through quite a lot of hoops to make best use of the aligned instructions. For instance, when it encounters an odd pixel address, it will process a single pixel at the start of the loop to force alignment for the destination address (which uses both read and write, and is thus more important). In fact, due to the possiblity of odd scanline pitch, the alignment is checked at the start of each scanline, and the correct instructions are used accordingly. 3. The code was built to handle weird input that is only 1 byte aligned. Thus, it should handle any alignment that is thrown at it, and if it doesn't that's a bug, but it should be fixable. 4. I don't recall the exact statistics, but I ran tests on aligned vs unaligned instructions while I was writing the code, and using the aligned instructions gives a large speed boost. I think it was about 20%, but I might be wrong. The key is that movdqa is a double path instruction and movdqu is a vector path instruction, and double path instructions are a whole lot quicker than vector path ones. ___ Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora! http://br.acesso.yahoo.com/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel diff -r -u e17/libs/imlib2/src/lib/amd64_blend.S e17_ori/e17/libs/imlib2/src/lib/amd64_blend.S --- e17/libs/imlib2/src/lib/amd64_blend.S 2005-08
Re: [E-devel] patch - imlib2 blend in AMD64
Hi, thanks for the info and help - nothing like hearing from who wrote the code... I then applied your patch and put the original lines back, with the aligned copy, but I now get again the same problem as before, segmentation faults.. The first line that gives me problem is #570, this is a piece of the code so you can find it: LEAVE SIZE(imlib_amd64_blend_rgba_to_rgb) PR_(imlib_amd64_blend_rgba_to_rgba): ENTER pxor %xmm4, %xmm4 movdqa c1(%rip), %xmm5 - *** here's the first problem xorq %rax, %rax movdqa mX000X000X000X000(%rip), %xmm6 movq [EMAIL PROTECTED](%rip), %r13 And I confirmed that now I compiled it with the .align 16 in the .text segment.. And just being curious now, could you perhaps explain what does a instruction like the above does? I mean, what does the mask in front of the %rip does, you take the address of the next instruction, apply (AND) a mask and move it to %xmm5? Sorry, just curious... Thanks, Tiago On Wed, 2005-08-24 at 18:45 -0600, John Slaten wrote: Since I wrote the original code, I thought I'd weigh in on this. 1. The memory that is causing the errors is statically allocated data in the .text segment, which I assumed would be correctly aligned and forgot to supply the .align directive. Adding this (as in the attached patch) _should_ fix the problem, though I have not tried to reproduce/test it. The code should then work with the aligned instructions as in the original. 2. The existing code jumps through quite a lot of hoops to make best use of the aligned instructions. For instance, when it encounters an odd pixel address, it will process a single pixel at the start of the loop to force alignment for the destination address (which uses both read and write, and is thus more important). In fact, due to the possiblity of odd scanline pitch, the alignment is checked at the start of each scanline, and the correct instructions are used accordingly. 3. The code was built to handle weird input that is only 1 byte aligned. Thus, it should handle any alignment that is thrown at it, and if it doesn't that's a bug, but it should be fixable. 4. I don't recall the exact statistics, but I ran tests on aligned vs unaligned instructions while I was writing the code, and using the aligned instructions gives a large speed boost. I think it was about 20%, but I might be wrong. The key is that movdqa is a double path instruction and movdqu is a vector path instruction, and double path instructions are a whole lot quicker than vector path ones. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] patch - imlib2 blend in AMD64
Hi, regarding the problem I mentionted about the new amd64 optimized functions in imlib2, I think I found the problem, has something to do with the fact that memory was not aligned in some (SSE2 128 bit) MOV operations - ie, I just changed a couple of MOVDQA to MOVDQU in file amd64_blend.S, treating memory as unaligned; Now if this has some other side effects (speed?) I don't know, but for me it worked now... Cheers, Tiago Gehring diff -u -r e17/libs/imlib2/src/lib/amd64_blend.S ../e17_ori/e17/libs/imlib2/src/lib/amd64_blend.S --- e17/libs/imlib2/src/lib/amd64_blend.S 2005-08-07 07:07:23.0 + +++ ../e17_ori/e17/libs/imlib2/src/lib/amd64_blend.S 2005-08-22 07:10:00.0 + @@ -168,8 +168,8 @@ ENTER pxor %xmm4, %xmm4 - movdqa c1(%rip), %xmm5 - movdqa m00XX(%rip), %xmm6 + movdqu c1(%rip), %xmm5 + movdqu m00XX(%rip), %xmm6 /* Move right to left across each line, */ /* processing in two pixel chunks */ @@ -565,9 +565,9 @@ ENTER pxor %xmm4, %xmm4 - movdqa c1(%rip), %xmm5 + movdqu c1(%rip), %xmm5 xorq %rax, %rax - movdqa mX000X000X000X000(%rip), %xmm6 + movdqu mX000X000X000X000(%rip), %xmm6 movq [EMAIL PROTECTED](%rip), %r13 /* Move right to left across each line, */ @@ -994,8 +994,8 @@ PR_(imlib_amd64_copy_rgba_to_rgb): ENTER - movdqa m0XXX0XXX0XXX0XXX(%rip), %xmm5 - movdqa mX000X000X000X000(%rip), %xmm6 + movdqu m0XXX0XXX0XXX0XXX(%rip), %xmm5 + movdqu mX000X000X000X000(%rip), %xmm6 leaq (%rsi, %r8, 4), %rsi leaq (%rdi, %r8, 4), %rdi
[E-devel] Re: emblem segfault starting up on athlon64
See thread above (imlib2, amd64 segfault), I had the same problem... For the emblem specific problem I attached a patch, it worked here. But as I said in the other thread I think there are other points with the same problem and a more general solution would be preferable.. Hello all, I get a segfault on starting up emblem. i am currently running Gentoo-2005.1 on an AMD64 as a 64bit insall... i didn't compile things with debugging symbols : / Running gdb emblem i get: (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 46912569548304 (LWP 9279)] WARNING: Weird line in resolv.conf: # Generated by dhcpcd for interface eth0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912569548304 (LWP 9279)] 0x2c6dc63b in __imlib_amd64_copy_rgb_to_rgba () ---Type return to continue, or q return to quit--- from /usr/lib/libImlib2.so.1 diff -u -r e17_ori/e17/libs/imlib2/src/lib/amd64_blend.S e17_ori2/e17/libs/imlib2/src/lib/amd64_blend.S --- e17_ori/e17/libs/imlib2/src/lib/amd64_blend.S 2005-08-22 18:53:55.0 + +++ e17_ori2/e17/libs/imlib2/src/lib/amd64_blend.S 2005-08-22 18:53:17.0 + @@ -1264,7 +1264,7 @@ PR_(imlib_amd64_copy_rgb_to_rgba): ENTER - movdqu mX000X000X000X000(%rip), %xmm5 + movdqa mX000X000X000X000(%rip), %xmm5 leaq (%rsi, %r8, 4), %rsi leaq (%rdi, %r8, 4), %rdi
Re: [E-devel] patch - imlib2 blend in AMD64
ok, found another line with the same problem - I saw this after seeing another post reporting also a amd64 issue with emblem and trying to start emblem myself... Now, before submiting another patch (emblem actually worked after changing one more instruction) I just wanted to speculate about the more general solution to this problem (I'm by no means an assembly expert, just did some reading on the net and took a better look at the code): What I think is that the problem with memory alignment resides only in the lines where data is copied from/to addresses using (RIP) relative addressing (at least it was the case in the lines that I changed before and now again). I mean, the problem is not with the source/destination pointers (parameters) because the assembly code already checks if these pointers are aligned and uses the best instruction acording to the case (and sure the performance drop for coping unaligned memory is really big), the lines that gave problems where just the ones that use something like movdqa 0xXX(%rip),%xmmN; The question is, there are a lot of other points of the code where a aligned copy to/from a relative address is made, should all of them be changed to unaligned or is there another solution? As said, all of this is just a suposition... On Mon, 2005-08-22 at 07:45 -0600, Tres Melton wrote: On Mon, 2005-08-22 at 07:29 +, Tiago Victor Gehring wrote: Hi, regarding the problem I mentionted about the new amd64 optimized functions in imlib2, I think I found the problem, has something to do with the fact that memory was not aligned in some (SSE2 128 bit) MOV operations - ie, I just changed a couple of MOVDQA to MOVDQU in file amd64_blend.S, treating memory as unaligned; Now if this has some other side effects (speed?) I don't know, but for me it worked now... Cheers, Tiago Gehring This is a poor solution in terms of speed. The correct solution is to ensure that the memory is properly aligned. For the time being it should be left that way (I noticed that raster committed the move unaligned data change). I have spoken with vapier (briefly) about it and am hoping to force the memory to be aligned on 128 bit boundaries. This will impact the stack size of the code and a few other things that I want to look into before offering a patch. A couple of hints: SSE instructions should be aligned on 16 byte (128 bit) boundaries. MMX instructions should be aligned on 8 byte ( 64 bit) boundaries. ASM: .align 16 C: Image * __attribute__ ((aligned (16))) image; Regards, RiverRat ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] imlib2, AMD64 segmentation fault in blend_rgba_to_rgba
Hello, since upgrading to imlib2 CVS I'm getting a segmentation fault int function __imlib_amd64_blend_rgba_to_rgba; I've seen that the code was changed to include specyfic optimizations for AMD64 and I tryed to debug the code but the problem lies in somewhere in the assembly code, so I wasn't really able to identify it. If I recompile imlib2 with --disable-amd64 all is fine (BTW I've noticed this problem using 'feh' image viewer); Here's the a backtrace of the execution: Starting program: /tmp/feh/feh/src/feh -dF /mnt/comum/fotos/05_08_wacken/ Program received signal SIGSEGV, Segmentation fault. 0x2b04b83f in __imlib_amd64_blend_rgba_to_rgba () from /usr/lib64/libImlib2.so.1 #0 0x2b04b83f in __imlib_amd64_blend_rgba_to_rgba () from /usr/lib64/libImlib2.so.1 #1 0x2b00a4f6 in __imlib_BlendRGBAToData (src=0x55b4e0, src_w=338, src_h=16, dst=0x54ca60, dst_w=341, dst_h=44, sx=0, sy=0, dx=2, dy=2, w=338, h=16, blend=1 '\001', merge_alpha=1 '\001', cm=0x0, op=OP_COPY, rgb_src=0 '\0') at blend.c:1710 #2 0x2b00a7eb in __imlib_BlendImageToImage (im_src=0x5496b0, im_dst=0x549630, aa=0 '\0', blend=1 '\001', merge_alpha=1 '\001', ssx=0, ssy=0, ssw=338, ssh=16, ddx=2, ddy=2, ddw=338, ddh=16, cm=0x0, op=OP_COPY, clx=0, cly=0, clw=0, clh=0) at blend.c:1762 #3 0x2b012d90 in imlib_render_str (im=0x549630, fn=0x5446c0, drx=2, dry=2, text=0x52d290 /mnt/comum/fotos/05_08_wacken/img_0379.jpg, r=0 '\0', g=0 '\0', b=0 '\0', a=255 'ÿ', dir=0 '\0', angle=0, retw=0x0, reth=0x0, blur=0, nextx=0x0, nexty=0x0, op=OP_COPY, clx=0, cly=0, clw=0, clh=0) at font_draw.c:131 #4 0x2affeaf3 in imlib_text_draw_with_return_metrics (x=2, y=2, text=0x52d290 /mnt/comum/fotos/05_08_wacken/img_0379.jpg, width_return=0x0, height_return=0x0, horizontal_advance_return=0x0, vertical_advance_return=0x0) at api.c:3113 #5 0x2affe850 in imlib_text_draw (x=2, y=2, text=0x52d290 /mnt/comum/fotos/05_08_wacken/img_0379.jpg) at api.c:3065 #6 0x0040e3d9 in feh_draw_filename (w=0x52a710) at imlib.c:724 #7 0x00407eb8 in winwidget_render_image (winwid=0x52a710, resize=800, alias=1) at winwidget.c:548 #8 0x0040892c in winwidget_create_from_file (list=0x52d2f0, name=0x52a6c0 feh [1 of 138] - /mnt/comum/fotos/05_08_wacken/img_0379.jpg, type=1 '\001') at winwidget.c:149 #9 0x0041128b in init_slideshow_mode () at slideshow.c:64 #10 0x0040606c in main (argc=3, argv=0x7fe3de98) at main.c:81 - Thanks, Tiago Gehring ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
