I finally succeed remote debugging from my windows machine to remote linux binary.
I can almost do everything except few things. Forexample I can't insert break points by enabling breakpoint of line by mouse click. But if I write :
b main
Note: breakpoint 1 also set at pc 0x401378.
Breakpoint 2 at 0x401378: file src/test.cpp, line 18.
to the eclipse console breakpoint,break point working.
Does anyone has any idea about that? Why UI breakpoint is not working .
Secondly lets say I add break point to line 12.(it happens very often any point in program 12 is just a example) When I "continue", I am not being able to execute "next","step" or view variables but if I put one more break point to one line after line 13 and "continue" everything is back normal again. I am again being able to use "next","step" etc...
This is disturbing me because I need to add unnecessary break points for this situation.
Any help will be appriaciated about those two problems related with remote debugging with eclipse UI.
Related
Looks like a stupid question, but I just can't make the code execution stop at breakpoint
I tried to run the project by both pressing F9 and F11, but it still does not stop at the breakpoint. I use the local url http://127.0.0.1:8000/task_list/ which should call the createTask view. And it does actually call the view, and everything works perfect with the only exception that the debugger ignores all my breakpoints
Most major ide's have two different ways of running normally,
Debug - This is usually denoted by some sort of bug image (as shown in your screenshot) or separate symbol
Run - This is usually a "play" button
The debug mode is the one you want, this is the one that inserts debug symbols. The run doesn't set any of these up so you will find that your program may run slightly faster this way, which makes it more advantageous when modifying files that don't require you to restart the server.
I'm learning how to use ncurses and I'm in a weird situation.
It seems my output can't go over 24 lines.
Moreover, whenever I run my software, and the execution finishes his job, my terminal stops working as before, and I have 2 different situations:
if I've launched my run from a line behind line 24 I can use the terminal, but if I keep scrolling when at the last line of the window, nothing more happens: all input and output keep happening in the last line, without any new line appearing at enter pressure.
if I've launched the run above line 24 the terminal will only become 24-lines high.
Both situations require me to reset the terminal, then everything works again.
I'm on MAC OSX machine.
There is a problem with the screen-size:
The easiest one to see is if you has LINES environment variable set to 24. The use_env manpage gives some clues about that.
The reason why it sounds like a problem with screen-size is that the description of the problem suggests that the program is setting the scrolling region to 24 lines.
If there is no problem with LINES, then a place to check is by running stty -a to see what the operating system supposes the screen-size to be. That is reported on the first line of stty's output as "rows".
In some cases (for instance in remote network connections), it is possible to have a session where the remote host cannot obtain the screen-size. As a workaround, you could run the resize program (an xterm utility) to update the operating system's notion of the screen-size.
By the way, your other question NCurses not restoring terminal behavior appears to be a duplicate of this. You should consolidate your questions into a single one which provides enough information for someone to offer useful information about the problem.
I know the answer to this, I'm putting it up here for others to see it
If you use eclipse CDT, you probably understand that eclipse isn't a debugger, it's just an application front-end, specifically to GDB. So when debugging C++ programs, you're actually just using GDB in a more comfortable manner. If you ever have to debug a multithreaded program in eclipse CDT, you'll realize that things quickly get hectic because when you hit a breakpoint, all threads stop, and when one tries to execute a single line in a specific thread, it also runs the other threads. In order for it to work properly, the threads have to be able to be run arbitrarily and exlusively-so that when the programmer executes a single line, it only executes the specific thread.
So, by default, gdb's settings by default leave the "scheduler-locking" turned off. If you debug multithreaded applications you'll understand that this must be on in GDB in order for the desired behavior to be achieved. How does one run this command:
set scheduler-locking on
in GDB within eclipse CDT?
At least one way to do it that certainly solves the problem is knowing how to navigate the immense set of features that eclipse offers. Typically, when a program starts, eclipse CDT switches the console window (if you have it open, typically it's on the bottom) to show the input/output of the program.
But you can change this if you didn't know-see this image. That button on the second to last right-the blue one that looks like a monitor-you can select the GDB input console. It was discussed also in this thread.
From there merely type the command.
SOLVED, BUT NEED A BETTER SOLUTION
But now that this has been solved, to solve it in a better way as a matter of convience; having to type set scheduler-locking on every time a program starts is silly. But the problem with loading a gdbinit file is that the gdbinit file gets sourced before eclipse has set the program for gdb to solve. This is a problem, as it causes the debugger view to hang within eclipse, as gdb complains. To understand what is happening, try and fire up gdb, then give the command without loading a binary to execute. It fails-so how does one set this as an option that is sticky?
Maybe if you add the following gdb script which could set the variable when the program stops and turns it off if you continue:
define hook-step
set scheduler-locking on
end
define hookpost-step
set scheduler-locking off
end
define hook-run
set scheduler-locking off
end
define hook-continue
set scheduler-locking off
end
My answer is derived from the one by #user1448557 . Unfortunately, I don't currently have enough reputation to comment on it (or to upvote it by the way). The strategy seems great, but the answer might be a bit outdated because it doesn't involve "set scheduler-locking step". I have put the following in my gdb initialization file (within my Eclipse project) and it does what I want.
#inspired from [link to this thread][1]
define hookpost-run
set scheduler-locking step
end
With regards to the comment by #rbaleksandar, Eclipse CDT launch configurations allow one to specify a "GDB Command File" and the default is usually .gdbinit
I have a C++ app that will throw an exception when I try to single step from a breakpoint. For example:
1) Start app from VS2010 0 debugger is attached.
2) Set a breakpoint. It doesn't seem to matter where.
3) Do something in the app so that it hits the break point.
** VS2010 hits the break point
4) Single step the debugger to the next line of code.
VS2010 pops up a message box with this exception:
"Unhandled exception at 0x087df66f in SimpleGraphSDI.exe: 0xC0000005: Access violation."
Note that if I set a breakpoint on two consecutive lines of code, and press run to advance from one line to another, the app "runs" to the next line of code with no issues. The access violation is only when I use the single step command from VS2010.
Some code in the app has been around since VC6 and maybe earlier. However do not know if this is relevant.
UPDATE: The exception when single stepping the debugger does not occur if I start the app, and then attach the debugger after the app has started.
I had this exact same issue. I was able to solve it by starting VS from the command line telling it to reset the UI to default (/ResetSettings) Details on the command line arguments are here
I did not need to reboot after resetting VS, but I did a full rebuild of the project after completing the reset of the environment.
A work around for this problem is to disable RPC debugging.
In the Visual Studio 2010, Visual Studio 2010 SP1 toolbar select below steps -
Tools->Options->Debugging->Native and deselect "Enable RPC debugging"
There maybe exist a thread that somehow detects that the code is being debugged step by step and pagefaults in response to prevent you from debugging. Try to locate that thread by suspending threads one by one.
Also, is address 0x087df66f always the same? If it is then you can set a breakpoint there and look around when the breakpoint is hit.
I've read the thread break whenever a file(or class) is entered. And I now understood the basic mechanism how to automatically set breakpoints in the classes. However, the solution that thread provided is focused on .net framework. My problem is how to deal with it in standard C++. We use vc 10 compiler on windows 7 platform.
Besides, we prefer methods which do not need recompile when we rechoose the class which we want to inspect since it is a huge project and recompilation takes a lot of time.
Thanks in advanceļ¼
You can do it from the IDE:
http://blogs.msdn.com/b/habibh/archive/2009/09/10/class-breakpoint-how-to-set-a-breakpoint-on-a-c-class-in-the-visual-studio-debugger.aspx
The answer Emile Cormier gives is a good solution. When I try to add a breakpoint "Stack::* " as the link says, I found there is no red point on the left of code lines until I start debugging the program. After stopping the program, the red points disappear, but the break point window will keep track of every breakpoint and you can turn to the code by double clicking the breakpoint in the breakpoint window.
As far as i know, you can only set memory breakpoints (break whenever the contents of a certain memory address is read/written) and then manual breakpoints (break on a certain line of code).
Your best bet may be to set a breakpoint at the beginning of the function call(s) you want to debug.