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). > I have to get back to that tomorrow. I'm still at uni and my girlfriend wants to go home, what can i do :). However i just traced the problem back to the attached eap file. If I use a different file for the eterm everything's ok. Unless don't find the reason before I'll continue debugging tomorrow. Thanks your time and E17 :)
eterm.eap
Description: Binary data
