On Mon, 24 Jul 2006 01:43:50 +0900,
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote:
| On Mon, 24 Jul 2006 01:28:12 +0900 (JST) Yasufumi Haga
| <[EMAIL PROTECTED]> babbled:
|
| > Hi all
| >
| > During playing a game called "Sol" which is a GTK based card game
| > program, CPU usage went up to 100%, and after that E17 crashed.
| > I built this E17 binary with the sources downloaded on July 15 or 16.
| > Though I may need to update E17 and EFLs, I thought I needed to
| > report this crash to the list before updating them. Here's the
| > backtrace:
| >
| > (gdb) bt
| > #0 0x405a1a92 in select () at regexec.c:1576
| > #1 0x404afa84 in _XlcPublicMethods () from /usr/X11R6/lib/libX11.so.6
| > #2 0x4041d371 in _XRead () from /usr/X11R6/lib/libX11.so.6
| > #3 0x4041cfc4 in _XReadEvents () from /usr/X11R6/lib/libX11.so.6
| > #4 0x4040e2c0 in XNextEvent () from /usr/X11R6/lib/libX11.so.6
| > #5 0x080cd7cf in e_alert_show (
| > text=0x8126fa0 "This is very bad. Enlightenment has segfaulted.\nThis is
| > not meant to happen and is likely a sign of a\nbug in Enlightenment or the
| > libraries it relies on.\n\nYou can gdb attach to this process now to
try"...)
| > at e_alert.c:129
| > #6 0x080b6f67 in e_sigseg_act (x=11, info=0xbffc2f10, data=0xbffc2f90)
| > at e_signals.c:53
| > #7 <signal handler called>
| > #8 0x406023f7 in main_arena () from /lib/i686/libc.so.6
| > #9 0x406023e4 in main_arena () from /lib/i686/libc.so.6
| > #10 0x4022e7d9 in _ecore_main_fd_handlers_call () at ecore_main.c:414
| > #11 0x4022ecaf in _ecore_main_loop_iterate_internal (once_only=0)
| > at ecore_main.c:630
| > #12 0x4022de03 in ecore_main_loop_begin () at ecore_main.c:79
| > #13 0x08063a7c in main (argc=1, argv=0xbffff494) at e_main.c:670
| > #14 0x404e0c1f in __libc_start_main (main=0x806215c <main>, argc=1,
| > ubp_av=0x814a038, init=0x811f5cc <__libc_csu_init>,
| > fini=0x811f614 <__libc_csu_fini>, rtld_fini=0xbffc21f4, stack_end=0x0)
| > at ../sysdeps/generic/libc-start.c:225
| > (gdb) quit
|
| thanks for the backtrace :) good users report things like this. the only
| problem is - this doesn't help much as seemingly the fd handlers have been
| corrupted or some undiscovered bug in ecore fd handlers has been hit - i doubt
| the ecore bug so what corrupted the fd handlers - not sure. i can't do a lot
| more than that given this... so i'm kind of stuck. :( all i can say is "update
| and if it happens again - report again, maybe dig into the fd handlers and
| print out some internal variables, struct info etc." to see if the fd handler
| is corrupt and how... or what it is inside the fd handlers call function that
| is goign bad - but given line number fdh is probably pointing to garbage
memory
| so it's been corrupted or something deeper is wrong.
OK. I'll update my environment on this weekend.
Regards.
---
"Thank you for telling me the truth." --- HAL9000 in "2010"
Yasufumi Haga [EMAIL PROTECTED]
http://homepage3.nifty.com/peterpan/
fingerprint:0EFA 299A BC32 7D68 1FEF BA2B 804E 9B15 C4F0 F9F0
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
