From: Carsten H. (T. R. <ra...@ra...> - 2010-12-12 14:34:00
|
On Sun, 12 Dec 2010 15:30:49 +0100 Thomas Sachau <to...@ge...> said: > Am 12.12.2010 02:20, schrieb Carsten Haitzler (The Rasterman): > > On Sat, 11 Dec 2010 17:24:48 +0100 Thomas Sachau <to...@ge...> said: > > > >> Since irc currently seems a bit silent, let me post the last 2 backtraces > >> here, so someone can have a look and either fix those issues or point me to > >> the issue i have on my machine, both backtraces first contain the "bt" and > >> afterwards a "bt full", both with gdb attached to the crashed/segfaulted e. > > > > unfortunately both traces say "the bug happened somewhere else earlier and > > memory has been stomped over and is later causing this crash". you'll > > want/need to run e using valgrind to help spot the original point of error. > > note - before you do tyhis ensure that you have everything up to date and > > built in-sync (ie updated to the same svn revision for everything and all > > rebuilt - gdb debugging on, also you might want to limit optimization to > > -O, not -O2 or -O3 - no inlining). that may give the actual problem. > > > > http://trac.enlightenment.org/e/wiki/Debugging > > > > for how to run a 2nd X (or even use Xephyr instead as your 2nd X). > > > Valgrind does not help in this case, since i am not able to produce those > problems with e running inside of valgrind. I can produce it without the > slowdown of valgrind without problems. So the problem may be a race condition. if you can't grab the bug earlier with a backtrace from valgrind... then i dont know how it's going to be found. short of reproducing it under valgrind either where you are, or some other developer is. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |