SlickEdit Product Discussion > SlickEdit®

trouble with integrated debugger

(1/2) > >>

jaykay:
I have read the the thread "vsdebugio exits with error: -100" with high interest as I have a similar problem.

After rebooting my system, the debugger works well with my project for the first debug session. When I start the integrated debugger the second time, the debugged program is started but the debugger is not able to attach to the debugged process. I then have to kill the debugged process manually.
When I switch to a different workspace (Hello World) the debugger works with this project.
After switching back to my project the debugger again does NOT work. After rebooting the system the debugger works with my project for the first debug session.

Symptoms:
After starting the debug session SlickEdit is busy for 30 seconds (debugger timeout). Trying to suspend the debugged process results in another 30 seconds "lock up" of slickedit. Then I get the Message
"Error suspending debugger. Timed out waiting for response from GDB."

Any suggestions what could be the problem ?


System information
- PIII 800MHz, 256MB
- Suse Linux 9.2
- SlickEdit V11 for Linux

Information on my project
- GNU C++ project with two modules (executable and shared library)
- using sockets and pthreads

jaykay:
Hello,

I disabled the  "Build first" option (Project-->Project Properties --> Tools --> Debug) and the problem disappeared. After reenabling the "Build First" option, the integrated debugger still works.
I ran a file compare on the the backup and the current project files (.vpj) and the only difference was the BuildFirst="1" entry.

One thing that happended this morning before I was playing around with the "Build first" option was a hanging SlickEdit IDE after trying to build my project containing a source file with an deliberately inserted syntax error (just added "abc" at the end of the file). I had to kill the vs process.

Regards

jaykay

jaykay:
Hello,

from the thread's read count I can see, that other SE users are also interessted in this problem. So I post my latest expierences.

At the moment it seems as killing all running SE processes (vs, vsdebugio,...) once (vs exits with code 99), solves the problem until the next linux reboot.

The following steps represent my current workaround
1.) Boot Linux
2.) start SlickEdit
3.) kill all SlickEdit processes (vs, vsdebugio, vsbuild)
  3b.) if  a debug session has been started, kill the process being debugged also
4) start SlickEdit

Does anyone have a similar problem ?

Regards

jaykay

jaykay:
Hello,

just to summarize the integrated debugger problem.

Symptoms:
- Debugger reports "unable to set breakpoint..." on startup of a debug session.
  I have to set breakpoints when the debug session is active.
- Setting breakpoints does not work reliably
  ("...unable to set breakpoint...").
  I can't set a breakpoint in file A.cpp line=513, but I can set a breakpoint
  elsewhere and the step through to line 513.
- debugging does only work for the first debug session after booting
  The second debug session does hang.
  See below for how to workaround this problem

Steps to reproduce the behaviour/workaround
1.) Boot Linux
2.) start SlickEdit (load C++ project)
3) start debug session (Debug-->Start)
4) stop debug session (Debug --> Stop)
5) start debug session once again
    SE will now wait for GDB response and timeout after 30 secs
6) stop debug session
    SE will stop the debug session but the debugged process is still running.
    Killing the debugged process and restarting the debugger will not solve
    the problem.

Workaround starts now
7) kill all SlickEdit processes (vs, vsdebugio, vsbuild)
    I do a "ps aux | grep vs" to find the PIDs

8) kill the debugged process
9) start SlickEdit again.
10) now debugger will work
     I can start and stop debug sessions without problems.


jaykay

Dennis:
What version of GDB are you using?  If you start a debug session and then go to "Debug" > "Debugger Options..." and click on the "Info" tab, you will see the complete information about which GDB you are using.

Exactly what kind of debugging session are you starting, remote, local, attach to PID?

With respect to the breakpoint problem, let me venture a guess.  Is the breakpoint in the shared library?  If so, then it's natural that the breakpoint can't be set immediately when the debugging session is started, since GDB doesn't know about those modules yet.  Unfortunately, using the MI interface, deferred breakpoints do not seem to work at all with GDB (as of 6.4, despite what the docs say).

Navigation

[0] Message Index

[#] Next page