Each time I choose 'run' it creates a DebugServer (in the debug view). Almost all the context menu options are disabled, including 'Terminate' option.
Is there a way to get rid of these without restarting Eclipse (every dozen runs or so)?
Thanks,
Chris.
Normally, after you will Terminate or Disconnect debug session, it will be marked as
<
terminated>
DebugServer [BlackBerry Simulator]
<
disconnected>RIM JVM
and you can remove it with context menu Remove All Terminated
Otherwise something may be wrong with system (conflict with system defence software, wrong BB eJDE setup, insufficient memory/CPU resources etc)
However you can always terminate debug server by killing fledge.exe and BbDevMgr.exe
Related
I'm using VS Code to write and debug a C++ program binding to libfuse.
Unfortunately, if you kill a libfuse process with SIGKILL, you then have to use sudo umount -f <mountpoint> before you can start the program again. It's a minor nuisance if I have to do this every time I want to stop or restart debugging, especially as I shouldn't have to authenticate to do such a regular task (the sudo is somehow necessary despite the mount occurring as my user).
While I think this is mainly FUSE's fault (it should gracefully recover from a process being ungracefully killed and unmount automatically instead of leaving the directory saying Transport endpoint is not connected), I also think there should be a way to customise VS Code (or any IDE) to run some clean-up when you want to stop debugging.
I've found that entering -exec signal SIGTERM in the Debug Console will gracefully unmount the directory correctly, stop the process and tell VS Code it's no longer debugging (status bar changes back from orange to blue). But I can't seem to find a way to automate this. I've tried using a .gdbinit file, with some inspiration from this question:
handle SIGTERM nostop
# This doesn't work as hook-quit isn't run when quitting via MI mode, which VS Code uses...
define hook-quit
signal SIGTERM
end
But as noted in the linked question, GDB ignores quit hooks when in MI mode, and VS Code uses MI mode.
The ideal solution for me would be if I could put something in a .vscode configuration file telling it to send -exec signal SIGTERM when I click the stop or restart buttons (and then wait for whatever notification it's getting that debugging has stopped, before restarting if applicable) but I imagine there probably isn't an option for that.
Even if the buttons can't be customised, I'd be happy with the ability to have a keybinding that would just send -exec signal SIGTERM to the Debug Console without me having to open said console and enter the command, though the Command Palette doesn't show anything useful here (nothing that looks like it will send a specified Debug Console command), so I don't expect there's a bindable command for that either.
Does anyone have any suggestions? Or would these belong as feature requests over on the VS Code github? Any way to get GDB to respect its quit hook in MI mode, or to get FUSE to gracefully handle its process being killed would be appreciated too.
Is there any way to kill an Eclipse background operation without killing Eclipse itself?
Specifically, I want to kill stalled Subclipse SVN operations. Clicking 'cancel' pops up a little Cancel Requested message, but the operation still sits there forever blocking everything else.
This is Eclipse Helios on Windows 7 if that makes any difference.
I was able to unstuck Eclipse (it was stuck on a large file diff) using the following steps.
Preparations: I always start Eclipse with the eclipse-console: Add start parameter -console in eclipse.ini (first line)
The console always remains responsive even when the eclipse UI freezes
I found the following commands in the console: help threads
List all threads: threads
Stop a thread: threads stop THREAD-NAME
UPDATE: I found out, that usually the "main" thread causes the freezing. Thus the solution is:
Type this in the eclipse console:
threads stop main
This will trigger/throw an Exception in that thread, effectively interrupting what it was doing (being stuck).
This might cause other side-effects (depending on what action was interrupted and where), but i had no problems with it so far.
Killing the task from the Progress window (Window->Show View->Other|General->Progress or Alt+Shift+Q, Q | General->Progress).
Then choose the offending thread and click the red square.
Note it sometimes takes a delay before the kill occur, you may also have to kill other thread in there to get what you want. Lastly it does not always work, if this fails I usually just restart eclipse.
Hope this helps
I was able to stop/terminate the hanging SVN commit process by briefly disconnecting the network adapter. This saved me from killing the Eclipse process, which if not terminated gracefully is known to cause other headaches.
If you go to window Progress in Eclipse and click red square to Stop:
and next, red square becomes gray square and process i frozen (Cancel Requested):
You must use Task Manager (Alt+Ctrl+Del on Windows) for kill process. Go to tab Processes, find process javaw.exe* and click End Process.
The result: frozen process in Eclipse was closed but your Eclipse wasn't closed.
* Process with name javaw.exe is for WildFly server. For Subclipse SVN can be another name of proces.
I'm not sure, but from the Debug perspective, you may be able to view the thread that's performing the background operation and kill it from there for quicker exit.
In console window, open "Open OSGi Console" from drop button.
In this console you can type command threads. This will show all running threads.
You can kill process with command threads stop '<Process name>'. Remember to use single apostrophe ' surrounding <Process name>, otherwise it won't work.
For example, I had to type:
threads stop 'Worker-12: Refresh DSLD scripts'
I had a problem where the external compiler I was using froze up when I tried to cancel the build operation. It was stuck in the "Cancel Requested" state. I went to the Windows Task Manager and found my compiler process and terminated it. That allowed Eclipse to continue and successfully cancel the operation.
Keep clicking on clean console, it will show the back ground processes, keep killing one by one.
I made this by opening console in eclipse and typing 'threads'. And then 'threads stop thread-name'.
In Lunux you can list all the Eclipse processes
ps -edf | grep eclipse
Then you choose the child process (the backgound doing Java process) of the main process (the Eclipse GUI Java process) of the starting shell process.
Example:
myself 21821 1222 0 09:28 ? 00:00:00 /local/eclipse/jee-2021-06/eclipse
myself 21839 21821 8 09:28 ? 00:24:53 /usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/java -Dosgi.requiredJavaVersion=11 -Dosgi.instance.area.default=#user.home/eclipse-workspace ... much more ...
myself 21965 21839 0 09:29 ? 00:01:48 /usr/lib/jvm/java-11-openjdk-amd64/bin/java -cp /local/eclipse/jee-2021-06/eclipse/../../../../home/myself/.p2/pool/p ... much more ...
The child in the chain of processes is the one with the proc-id 21965. This one you have to kill.
Try kill -2 <proc-id> and, if it did not work, kill -9 <procid>
I am looking for assistance with the proper GDB / OpenOCD initializion and running commands (external tools) to use within Eclipse for flash and RAM debugging, as well as the proper modifications or additions that need to be incorporated in a makefile for flash vs RAM building for this MCU, if this matters of course.
MCU: STM32F103VET6
I am using Eclipse Helios with Zylin Embedded CDT, Yagarto Tools and Bins, OpenOCD 0.4, and have an Olimex ARM-USB-OCD JTAG adapter.
I have already configured the ARM-USB-OCD and added it as an external tool in Eclipse. For initializing OpenOCD I used the following command in Eclipse. The board config file references the stm32 MCU:
openocd -f interface/olimex-arm-usb-ocd-h.cfg -f board/stm32f10x_128k_eval.cfg
When I run this within Eclipse everything appears to be working (GDB Interface, OpenOCD finds the MCU, etc). I can also telnet into OpenOCD and run commands.
So, I am stuck on the next part; initialization and commands for flash and RAM debugging, as well as erasing flash.
I read through several tutorials, and scoured the net, but have not been able to find anything particular to this processor. I am new to this, so I might not be recognizing an equivalent product for an example.
I'm working with the same tool chain to program and debug a STM32F107 board. Following are my observations to get an STM32Fxxx chip programmed and debugged under this toolchain.
Initial Starting Point
So at this point you've got a working OpenOCD to ARM-USB-OCD connection and so you should be all set on that end. Now the work is on getting Eclipse/Zylin/Yagarto GDB combination to properly talk to the STM32Fxxx through the OpenOCD/Olimex connection. One thing to keep in mind is that all the OpenOCD commands to issue are the run mode commands. The configuration scripts and command-line options to invoke the OpenOCD server are configuration mode commands. Once you issue the init command then the server enters run mode which opens up the set of commands you'll need next. You've probably done it somewhere else but I tack on a '-c "init"' option when I call the OpenOCD server like so:
openocd -f /path to scripts/olimex-arm-usb-ocd-h.cfg -f /path to targets/stm32f107.cfg -c "init"
The following commands I issue next are done by the Eclipse Debug Configurations dialogue. Under the Zylin Embedded debug (Native) section, I create a new configuration, give it a name, Project (optional), and absolute path to the binary that I want to program. Under the Debugger tab I set the debugger to Embedded GDB, point to the Yagarto GDB binary path, don't set a GDB command file, set GDB command set to Standard, and the protocol to mi.
The Commands Tab - Connect GDB to OpenOCD
So the next tab is the Commands tab and that's where the meat of the issue lies. You have two spaces Initialize and Run. Not sure exactly what the difference is except to guess that they occur pre- and post-invocation of GDB. Either way I haven't noticed a difference in how my commands are run.
But anyway, following the examples I found on the net, I filled the Initialize box with the following commands:
set remote hardware-breakpoint limit 6
set remote hardware-watchoint-limit 4
target remote localhost:3333
monitor halt
monitor poll
First two lines tell GDB how many breakpoints and watchpoints you have. Open OCD Manual Section 20.3 says GDB can't query for that information so I tell it myself. Next line commands GDB to connect to the remote target at the localhost over port 3333. The last line is a monitor command which tells GDB to pass the command on to the target without taking any action itself. In this case the target is OpenOCD and I'm giving it the command halt. After that I tell OpenOCD to switch to asynchronous mode of operation. As some of the following operations take a while, it's useful not to have OpenOCD block and wait for every operation.
Sidenote #1: If you're ever in doubt about the state of GDB or OpenOCD then you can use the Eclipse debug console to send commands to GDB or OpenOCD (via GDB monitor commands) after invoking this debug configuration.
The Commands Tab - Setting up the User Flash
Next are commands I give in the Run commands section:
monitor flash probe 0
monitor flash protect 0 0 127 off
monitor reset halt
monitor stm32x mass_erase 0
monitor flash write_image STM3210CTest/test_rom.elf
monitor flash protect 0 0 127 on
disconnect
target remote localhost:3333
monitor soft_reset_halt
to be explained in the following sections...
Setting up Access to User Flash Memory
First I issue an OpenOCD query to see if it can find the flash module and report the proper address. If it responds that it found the flash at address 0x08000000 then we're good. The 0 at the end specifies to get information about flash bank 0.
Sidenote #2: The STM32Fxxx part-specific data sheets have a memory map in section 4. Very useful to keep on hand as you work with the chip. Also as everything is accessed as a memory address, you'll come to know this layout like the back of your hand after a little programming time!
So after confirming that the flash has been properly configured we invoke the command to turn off write protection to the flash bank. PM0075 describes everything you need to know about programming the flash memory. What you need to know for this command is the flash bank, starting sector, ending sector, and whether to enable or disable write protection. The flash bank is defined in the configuration files you passed to OpenOCD and was confirmed by the previous command. Since I want to disable protection for the entire flash space I specify sectors 0 to 127. PM0075 explains how I got that number as it refers to how the flash memory is organized into 2KB pages for my (and your) device. My device has 256KB of flash so that means I have 128 pages. Your device has 512KB of flash so you'll have 256 pages. To confirm that your device's write-protection has been disabled properly, you can check the FLASH_WRPR register at address 0x40022020 using the OpenOCD command:
monitor mdw 0x40022020
The resulting word that it prints will be 0xffffffff which means all pages have their write protection disabled. 0x00000000 means all pages have write protection enabled.
Sidenote #3: On the subject of the memory commands, I bricked my chip twice as I was messing with the option bytes at the block starting at address 0x1ffff800. First time I set the read protection on the flash (kind of hard to figure out what your doing if you do that), second time I set the hardware watchdog which prevented me from doing anything afterwards since the watchdog kept firing off! Fixed it by using the OpenOCD memory access commands. Moral of the story is: With great power comes great responsibility.... Or another take is that if I shoot myself in the foot I can still fix things via JTAG.
Sidenote #4: One thing that'll happen if you try to write to protected flash memory is the FLASH_SR:WRPRTERR bit will be set. OpenOCD will report a more user-friendly error message.
Erasing the Flash
So after disabling the write protection, we need to erase the memory that you want to program. I do a mass erase which erases everything, you also have the option to erase by sector or address (I think). Either way you need to erase first before programming as the hardware checks for erasure first before allowing a write to occur. If the FLASH_SR:PGERR bit (0x4002200c) ever gets set during programming then you know you haven't erased that chunk of memory yet.
Sidenote #5: Erasing a bit in flash memory means setting it to 1.
Programming Your Binary
The next two lines after erasure writes the binary image to the flash and reenables the write protection. There isn't much more to say that isn't covered by PM0075. Basically any error that occurs when you issue flash write_image is probably related to the flash protection not being disabled. It's probably NOT OpenOCD though if you're curious you can take enable the debug output and follow what it does.
GDB Debugging
So finally after programming I disconnect GDB from the remote connection and then reconnect it to the target, do a soft-reset, and my GDB is now ready to debug. This last part I just figured out last night as I was trying to figure out why, after programming, GDB wouldn't properly stop at main() after reset. It kept going off into the weeds and blowing up.
My current thinking and from what I read in the OpenOCD and GDB manuals is that the remote connection is, first and foremost, meant to be used between GDB and a target that has already been configured and running. Well I'm using GDB to configure before I run so I think the symbol table or some other important info gets messed up during the programming. The OpenOCD manual says that the server automatically reports the memory and symbols when GDB connects but all that info probably becomes invalid when the chip gets programmed. Disconnecting and reconnecting I think refreshes the info GDB needs to debug properly. So that has led me to create another Debug Configuration, this one just connects and resets the target since I don't necessarily need to program the chip every time I want to use GDB.
Whew! Done! Kind of long but this took me 3 weekends to figure out so isn't too terribly bad I think...
Final sidenote: During my time debugging I found that OpenOCD debug output to be invaluable to me understanding what OpenOCD was doing under the covers. To program a STM32x chip you need to unlock the flash registers, flip the right bits, and can only write a half-word at a time. For a while I was questioning whether OpenOCD was doing this properly but after looking through the OpenOCD debug output and comparing it against what the PM0075 instructions were, I was able to confirm that it did indeed follow the proper steps to do each operation. I also found I was duplicating steps that OpenOCD was already doing so I was able to cut out instructions that weren't helping! So moral of the story: Debug output is your friend!
I struggled getting JLink to work with a STM3240XX and found a statement in the JLink GDB server documentation saying that after loading flash you must issue a "target reset":
"When debugging in flash the stack pointer and the PC are set automatically when the target is reset after the flash download. Without reset after download, the stack pointer and the PC need to be initialized correctly, typically in the .gdbinit file."
When I added a "target reset" in the Run box of the debugger Setup of Eclipse, suddenly everything worked. I did not have this problem with a Kinetis K60.
The document also explains how to manually set the stack pointer and pc directly if you don't want to issue a reset. It may not be the disconnect/connect that solves the problem but the reset.
What i use after the last sentence in the Comannd Tab - 'Run' Commands, is:
symbol-file STM3210CTest/test_rom.elf
thbreak main
continue
The thbreak main sentence is what makes gdb stop at main.
I'm working with Windows 7 64X and DebugView 4.76.0.0.
Logs isn't shown on DebugView.
I trying to write logs with Debug.WriteLine("Text"); and see nothing.
I can see that It's connected to my computer.
When I use DebugView V4.64.0.0 I get error message that it is already connected to other instance of DebugView, but I've checked and there isn't any other.
What can I do or check ?
BTW,
I can see the log in the output window.
Regards,
Eitan Gabay
To check if you really have another instance of debugview running, open up your task manager, and select "show processes from all users". Make sure that only one debugview is running.
When debugging through Visual Studio, Visual Studio actually competes against DebugView. If you were to compile your executable, and run it externally, you will see your log messages printed in DebugView.
One other thing that people sometimes overlook is that Debug.Write statements are excluded if a program is compiled for Release. However, you can still write to the trace if you use Trace.Write instead of Debug.Write.
All messages that you print go to a shared section of memory called DB_WINBUFFER link. It is important to realize that each windows session has its own "DB_WINBUFFER". Whenever DebugView detects that you are not in session 0, it will provide a "Capture Global" option. If your program is running as a windows service, then you will need to enable capture global (unless you are already in Session 0, which is only possible in Windows XP).
By default when using a webapp server in Eclipse Web Tools, the server startup will fail after a timeout of 45 seconds. I can increase this timeout in the server instance properties, but I don't see a way to disable the timeout entirely (useful when debugging application startup). Is there a way to do this?
In Eclipse Indigo, you can edit the default timeout by double-clicking on the server in the "servers" view and changing the timeout for start (see graphic). Save your changes, and you're good to go!
On the EclipseIDE, double click on the server
Admin panel opens up, click on the "Timeouts" tab
Put larger value in the "Start (in seconds)", may be 1800
Restart/Start the server
If everything is okay, the server should start.
Just another data point. If you see in your Console "Server startup in NNN ms", but the Server view still shows that it is trying to start, and then times out eventually killing the server, it might be that you have no plain HTTP connector configured. For example, if you have only a 2-way SSL connector configured in your Tomcat, it will start fine with the scripts in "TOMCAT_HOME/bin", but if you try to start it with the Eclipse Server view, it won't be able to open a connection to the HTTP port, and will terminate when it hits the timeout. (This was with a fairly old STS 2.1.0. Don't know if it's fixed in later versions)
Joe
Julie's answer gives you a long timeout, but not unlimited. You can move the server configuration file to the workspace, and then edit the xml file directly and set a limit greater than 1800. It's an ugly hack, but should work.
Goto Window > Preferences > Server
Set 'Server timeout delay' as Unlimited from drop-down menu.
or
Goto $WORKSPACE/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.wst.server.core.prefs
Add/update line machine-speed= -1
here, -1 ~ Unlimited
If you still has issue after changing timeout settings, then it's best to remove the server configuration in Eclipse (in Server view tab) and re-create it again.
Server --> New Server.
It worked for me.
yes this works, but the maximum limit is 1800, which is 30mins.
Sometimes when rebuilding our entire database (on server initial start) this can go for longer than 30mins and causes problems.
In eclipse 2019-09 (4.13.0) there is no UI capability to set an unlimited value. It must be between 1 and 84600 seconds (a day).
But if you edit the .metadata/.plugins/org.eclipse.wst.server.core/servers.xml file in the workspace and set the server's start-timeout attribute to a large number of in my case -1 it will not abort the server startup until such time is reached. I had to restart eclipse for the change to be read.
NOTE: using the UI to edit other values will coalesce your value to a value within the allowable range.