Carsten Haitzler (The Rasterman) wrote: > On Fri, 21 Oct 2005 15:55:37 +1300 jochen <[EMAIL PROTECTED]> babbled: > > >>OK, I just rebuild all of EFL and E with the above flags and the error >>is gone, so it seems it was a optimization bug, and I thought I was >>conservative with the optimization. Thanks for the explanations. Well if >>I find some time I might even dig into it to find out which compiler >>option it is, not tonight though, I'll go see the kiwis whip some >>kangoroo ass ;-) (for those who don't know what the heck I'm talking >>about, I'm going to watch the Australia against New Zealand rugby league >>game) > > > AARGH!!!!!! and now its gone? what version of gcc do you use? personalyl i > compile everything (in efl) with these cflags: -O2 -march=pentium4 -g -msse > -mmmx -pipe > > on my p4 boxes, and > -O2 -march=pentium3 -fomit-frame-pointer -msse -mmmx -pipe > > on my p3 boxes. i've never seen the bugs you are describing and i cannto > produce, reproduce or even make sens of the debug info you are getting. i > suspect it could be some compiler weirdness/bug. i'm not sure. but all in all > - > this is a hard thing to track. based on the bugs i have seen - they SEEM > impossible looking at the code, every time, UNLESS there is a compielr bug, OR > some memory corruption which i am unaware of to date :( > OK this is getting weirder and weirder I had just recompiled another cvs version of yesterday, CFLAGS=-g. This time I got a segfault when closing thunderbird. I'm not quite sure if this is the same bug but here is the backtrace
#0 0xffffe410 in __kernel_vsyscall () #1 0xb7d1b8cd in select () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7dbf135 in _XPollfdCacheDel () from /usr/X11R6/lib/libX11.so.6 #3 0xb7dbff89 in _XRead () from /usr/X11R6/lib/libX11.so.6 #4 0xb7dbfc00 in _XReadEvents () from /usr/X11R6/lib/libX11.so.6 #5 0xb7db1976 in XNextEvent () from /usr/X11R6/lib/libX11.so.6 #6 0x080bbe0b in e_alert_show ( text=0x80d80e0 "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:136 #7 0x080a82f6 in e_sigseg_act (x=11, info=0xbffdf6d0, data=0xbffdf750) at e_signals.c:54 #8 <signal handler called> #9 0x0809332f in e_object_unref (obj=0x368) at e_object.c:109 #10 0x080771d1 in _e_border_free (bd=0x85e4510) at e_border.c:2555 #11 0x08093313 in e_object_free (obj=0x85e4510) at e_object.c:92 #12 0x0809334f in e_object_unref (obj=0x85e4510) at e_object.c:111 #13 0x08081058 in _e_border_event_border_stack_free (data=0x0, ev=0x898dba8) at e_border.c:6378 #14 0xb7f47508 in _ecore_event_del (event=0x84111f0) at ecore_events.c:357 #15 0xb7f477c4 in _ecore_event_call () at ecore_events.c:445 #16 0xb7f4c775 in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:629 #17 0xb7f4b8eb in ecore_main_loop_begin () at ecore_main.c:79 #18 0x0805d97e in main (argc=1, argv=0xbffffcd4) at e_main.c:556 #9 0x0809332f in e_object_unref (obj=0x368) at e_object.c:109 109 obj->references--; 104 e_object_unref(E_Object *obj) 105 { 106 int ref; 107 108 E_OBJECT_CHECK_RETURN(obj, -1); 109 obj->references--; 110 ref = obj->references; 111 if (obj->references == 0) e_object_free(obj); 112 return ref; 113 } $1 = (E_Object *) 0x368 Cannot access memory at address 0x370 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/enlightenment, process 8125