Le 15.10.2013 23:38, Tazman Deville a écrit :
You're talking about moving every .configfile in my $HOME?
Yes.
That sounds a bit drastic, and possibly a bad idea.
Why that? It is only moving. Doing a backup, in fact. If you are feared by that, you can also create a new user, and copy configuration files one after the other until you have the same problematic behavior.
Can we narrow it down to what possible files might actually affect it without implementing such drastic measures?
I have no other idea... but theoretically, the problems should be related to graphical stuff. I would guess that it could be linked to gtk, fonts, and stuff like that. Take a look at it's dependency chain, and see what in it have some configuration files, that should give you a good hint.
Honestly, I tried to use the *dgb files. I had no results, I was never able to understand their use. It seems that it is better to compile the software with the -g option, and debug the compiled version. At least, you will have the source code, with comments, which makes things really easier, andOnly if it's written in a language I can make sense of, of course.
No. Even without knowing a language, you should be able to read comments, variable names and functions names. I personally consider that, in fact, comments are not as useful as it is taught. Good names for classes, functions and variables are the best documentation and makes comments almost useless. ( note the almost here... some comments are useful, sometimes, when you need to do hacking tricks )
VIM IS THE ONLY IDE!!!
I like vim a lot, but it is not an IDE. It is only an editor. My IDE is my whole system: i3, gdb and cgdb, vim, git, lxterminal, bash-completion, meld, man, opera... and no classic all-in-one IDE can compete with it for my needs, this I can assure you ;)
I don't thnk we're getting anywhere with gdb or other debuggers, becauseit's simply stopping and hanging at some point.Or maybe some other debugger will be able to tell me where, and possiblywhy?
As I said, gdb can. Because IDE are able to do so, and they are simply front-ends to gdb.
In fact, they are able to interrupt program at user's will.Here is a trick I have learn something like 10 years ago, when I was studying reverse engineering ( well, ok, cracking, but what has always interested me was to add features to closed source softwares. Or removes, so not only the cracking stuff ) : run the targeted program, interrupt it when it shows the (un)desired behavior, and ask the debugger to "run until RET ( asm instruction )" several times so that you finally are in the program itself ( at interrupt time, you will probably be in system functions or in a library ). This way, you can find the section which interest you, quickly.
Sadly, I was used to do that with softice ( a ring0 debugger, a very nice and efficient tool, able to debug the OS itself. I wonder why rr0d - it means Rasta Ring 0 Debugger - , the only one I knows able to run other OSes than windows, is not so known...), on windows. w32disasm or ollydbg too. Windows' debuggers are really very good tools, and I know no gdb frontend which can compete with them, sadly. But they are better for their interface, not because GDB lacks the feature. I simply do not know how to do that with GDB... If you or anyone else find how to, I am really interested.
But, I know that Code::Blocks is also able to interrupt a program you are debugging. I am certain of that, so GDB should be able to do so. I think I could find how it does it if I take the time to read the debugger plugin... I should do that now I think about it.