On Thu, 20 Oct 2005 17:09:25 +1300 jochen <[EMAIL PROTECTED]> babbled:
> Carsten Haitzler (The Rasterman) wrote: > > On Wed, 19 Oct 2005 18:40:43 +0900 Carsten Haitzler (The Rasterman) > > <[EMAIL PROTECTED]> babbled: > > > > > >>On Wed, 19 Oct 2005 22:16:49 +1300 jochen <[EMAIL PROTECTED]> > >>babbled: > >> > >> > >>>Carsten Haitzler (The Rasterman) wrote: > >>> > >>>>On Tue, 18 Oct 2005 20:37:41 +1300 jochen <[EMAIL PROTECTED]> > >>>>babbled: > >>>> > >>>> > >>>> > >>>>>Carsten Haitzler (The Rasterman) wrote: > >>>>> > >>>>> > >>>>>>On Tue, 18 Oct 2005 20:13:40 +1300 jochen <[EMAIL PROTECTED]> > >>>>>>babbled: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Carsten Haitzler (The Rasterman) wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>On Tue, 18 Oct 2005 17:30:16 +1300 jochen <[EMAIL PROTECTED]> > >>>>>>>>babbled: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>jochen wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>Hi guys, > >>>>>>>>>>I'm have another segfault. CVS of today. It happens when I close an > >>>>>>>>>>eterm with alt-right -> close. happens every time. Closing with > >>>>>>>>>>ctrl-alt-x or the close button works however. and it seems to only > >>>>>>>>>>happen with eterm of the apps I tried. Here is the backtrace > >>>>>>>>>>Cheers > >>>>>>>>>>Jochen > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>>correction, it also happens with gnome-terminal. However only when > >>>>>>>>>Eterm/gterm is started from menu or ibar. when started from another > >>>>>>>>>terminal they close fine > >>>>>>>> > >>>>>>>> > >>>>>>>>are you using any modules not shipped with e17? (engage etc.) ? > >>>>>>>> > >>>>>>> > >>>>>>>No turned them all off, do you need more info? > >>>>>> > >>>>>> > >>>>>>ok - one thing. go to the e17 src: > >>>>>> > >>>>>>make clean distclean > >>>>>>./configure (whatever options) > >>>>>>make > >>>>>>make install > >>>>>> > >>>>>>again - just in case. basically this backtrace makes no sense as bd->app > >>>>>>shoudl be a valid pointer or NULL as i read the code in front of me. the > >>>>>>value it has is really bogus. > >>>>>> > >>>>> > >>>>>Still the same, flags are CFLAGS="-g -O2 -march=pentium4" so nothing > >>>>>special. I just checked if there's an old installation floating around > >>>>>somewhere just in case, but nothing there. > >>>> > >>>> > >>>>grr - that shouldnt be that value (0x368 for the object pointer). thats > >>>>like a completely bogus value and i cant see how it happens... UNLESS the > >>>>border is being passed into a functiont hat expects a different type. i > >>>>shoudl likely go thru all objects and add type checks - i may catch it. > >>>>but what baffles me the border is the last struct member - and borders > >>>>are like the largest structs in e17 - so nothng shoudl be able to > >>>>overwrite it. > >>>> > >>>>ok. here is something i might suggest. > >>>> > >>>>start e under gdb (From another machine/console). > >>>>nos start an xterm or 2 > >>>>NOW > >>>>ctrl-c and set a breakpoint for e_border_new > >>>> > >>>>NOW continue the program. > >>>> > >>>>from an xterm run another program (xterm, gnome-terminal - doesnt matter) > >>>> > >>>>e shoudl freeze as the breakpoint is caught > >>>>go back to gdb > >>>>and step thrugh e_border_new > >>>>until it has allocated the bd struct. NOW. set a watch for bd->app and > >>>>continue. > >>>> > >>>>what shoudl happen is that e should then continue and trap again - print > >>>>bd->app when it traps. it should be valid ( a normal looking pointer) - it > >>>>ma trigger 2 or 3 times actually - but as long as its with valid pointers > >>>>we are ok. now close this new window as u did - hopefully the watch point > >>>>shoudl get triggered every time it does do a backtrace. one of them must > >>>>be setting it to this bogus value. if you can get a log of all of that - > >>>>we'll find the one that does it. (i hope). > >>>> > >>> > >>>OK I have done that, I never got to the point of closing the terminal. > >>>However bd->app is set to the wrong value when opening the window > >>>already. Attached are 3 gdb logs, the first one I step through watching > >>>bd->app until it is set to the fishy value. Number two I set > >>>e_focus_setup as a breakpoint as that was the last time bd->app was set > >>>before the weird value. I got a corrupted stack message at somepoint so > >>>I could not continue. In the third log a continued after bd->app was set > >>>to the value, and got a corrupt stack message a little after that. I > >>>hope these logs are somewhat useful, I'm quite new to the whole > >>>debugging business so if I need to do something differently just wack me > >>>with a clue bat. > >>>Cheers > >>>Jochen > >> > >>hmm - almost perfect. when u get a watchpoint trap - can you do a bt as well > >>at that time (so i can see the call tree/history of that watchpoint trap > >>point) :) > > > > > > oh - can you also do a list of the code (the list command). it seems right > > now that the watch point traps you are getting are bogus as it doesnt make > > sense where gdb is trapping - at all. hmmm. > > > ok I have done another backtrace, and I am totally lost with my > debugging knowledge. I would really like to understand a little better > so I actually know what I am doing next time. I have done backtraces and > lists at every watchpointtrap. Just before the point where the problem > occurs i have started to going through the code with step. But I don't > really get this. Do I understand backtraces correctly that #0 is the > function that was being executed which was called by function #1 etc? So > from the the log e_focus_setup is being called from e_border_new with bd > (border ?) parameter. This then calls ecore_window_button_grab but with > bd->win, so how is bd->app modified? Is this about right? yes that's right fn #0 was called by #1, and #1 called by #2 etc. basically now reading this backctrace... it makes no sense. bd->app cannot be modified where gdb s sayoing it is. it can't be. i suspect optimisations are causign the debugging to screw up. so compile evas, ecore, edje, eet, embryo ANd enlightenment with tese CFLAGS: -g3 -O0 -ggdb and make install again - and try this again. :( i'm still not seeing any sense in your backtraces here :( -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- 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
