I've only recently started experiencing an issue in Visual Studio Code while running applications in debug mode, I always get this error:
Failed to halt - Process 2152 has exited with status 0
Just after main() function exits, even when I import only fmt package and print "Hello World", or running applications those were previously working.
I pulled same project on another machine and run it (for example "Hello World" project). I'm getting the same error message.
Has anyone else experienced the same? It doesn't seem to occur when I run built applications using cmd (command prompt).
Related
I'm trying to debug a program in WinDbg. However, WinDbg won't run it after I launch it; after loading the binary, when I attempt to continue the program I get this error:
0:002> g
^ No runnable debuggees error in 'g'
Some relevant facts:
I'm using Windows 10.
The program in question is written in C and was built with MinGW.
The program is loaded, as I see it in the Task Manager. It just won't go beyond ntdll!NtWaitForWorkViaWorkerFactory.
There is no error in the program at this point; I'm just trying to get the thing running before I move on to my real problem (which is beyond the scope of this post).
I can attach to a running instance of this program just fine, I just can't launch new ones.
I can launch notepad.exe with WinDbg just fine.
I installed the Pardiso.jl with instructions on the package webpage. And when I run the test code, Julia just exited with the error message below. When I run from 568-574 it was not a problem. but when I try to use solve!() Julia just crushed. The link directs me to https://code.visualstudio.com/docs/supporting/troubleshoot-terminal-launch
I am not an expert with using external solver so would anyone kindly help me out?
The terminal process "julia.exe '-i', '--banner=no', '--project=C:\Users\catie.julia\environments\v1.6', 'c:\Users\catie.vscode\extensions\julialang.language-julia-1.4.3\scripts\terminalserver\terminalserver.jl', '\.\pipe\vsc-jl-repl-f9a2393d-4e4d-42ec-9aa9-acb076d5bde1', '\.\pipe\vsc-jl-cr-4f79880d-c78a-44bc-858d-92cdce1af703', 'USE_REVISE=true', 'USE_PLOTPANE=true', 'USE_PROGRESS=true', 'DEBUG_MODE=false'" terminated with exit code: 3221226356.
test code on Parsido package website
error message appears
I need to program in py 2.7 a function that
when active, it closes all connections to the internet of a client (It is a server-client socket connection)
Because I cannot just make the client turn off the internet (Because then we won't be able to communicate with him)
I thought to run a thread. That when active (When the server sends to the client "close_internet") the thread runs a while true function that closes all the browsers (and thus "closing" its internet connection). I will have a list of known browsers (not all) that the thread will actively close.
This line of code closes any process by name:
import os
import threading
def close_internet():
while 1:
try:
os.system('taskkill /f /im MicrosoftEdge.exe')
except:
pass
threading.Thread(target=close_internet, args=()).start()
When I run this code, it does work, closing explorer when I open it (Explorer just for testing, you can change to chrome.exe or firefox.exe)
However, in the console it prints some scary errors, all the time:
ERROR: The process "MicrosoftEdge.exe" not found.
ERROR: The process "MicrosoftEdge.exe" not found.
ERROR: The process "MicrosoftEdge.exe" not found.
ERROR: The process "MicrosoftEdge.exe" not found.
ERROR: The process "MicrosoftEdge.exe" not found.
ERROR: The process "MicrosoftEdge.exe" not found.
What can I do? I only need this program to work in the background, without the user noticing with those errors.
The errors appear (not surprisingly) when I don't have explorer open.
When I do have it open, it works fine and prints:
ERROR: The process "MicrosoftEdge.exe" not found.
ERROR: The process "MicrosoftEdge.exe" not found.
SUCCESS: The process "MicrosoftEdge.exe" with PID 10808 has been terminated. # <-- this line
ERROR: The process "MicrosoftEdge.exe" not found.
The function is programmed on the client-side!
How can I fix it?
And secondly, is this the right way to close a process by its name? is it efficient? or is there a more efficient way to close a process (Maybe using its PID makes it faster...) I'd like to hear your advice.
Thanks!
Try using the subprocess module. I don't think you need Threading for this task.
Here is the code i use to open windows explorer and highlight a file.
subprocess.Popen(r'explorer /select, %s%s'%(self.cwd, ofile))
It should be easy to modify for your task. Also that code is assuming that Edge is open and the name is MicrosoftEdge.exe is the process name. Assume nothing and see if you can get a list of running processes using python, scan through that list and check if the application you want to close is already open. Here is a link with some information on getting the list of processes running on windows.
i am coding in Qt 5.7 on win 7. my app is run correctly. but when i use the debugger, a error dialog box showed: the GDB process terminated unexpectedly (exit code3).
last part of debugger log :
>~"../../../../src/gdb-7.10.1/gdb/utils.c:1071: internal-error: virtual memory exhausted.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nCreate a core file of GDB? "
>~"(y or n) [answered Y; input not from terminal]\n"
dUNEXPECTED GDB STDERR:
dThis application has requested the Runtime to terminate it in an unusual way.
dPlease contact the application's support team for more information.
dGDB PROCESS FINISHED, status 0, exit code 3
dNOTE: ENGINE ILL ******
dFORWARDING STATE TO InferiorShutdownFailed
dState changed BY FORCE from InferiorStopOk(14) to InferiorShutdownFailed(17) [master]
dState changed from InferiorShutdownFailed(17) to EngineShutdownRequested(19) [master]
dQUEUE: SHUTDOWN ENGINE
dCALL: SHUTDOWN ENGINE
dPLAIN ADAPTER SHUTDOWN 19
dINITIATE GDBENGINE SHUTDOWN IN STATE 14, PROC: 0
dNOTE: ENGINE SHUTDOWN OK
dState changed from EngineShutdownRequested(19) to EngineShutdownOk(21) [master]
dState changed from EngineShutdownOk(21) to DebuggerFinished(22) [master]
dQUEUE: FINISH DEBUGGER
dNOTE: FINISH DEBUGGER
dHANDLE RUNCONTROL FINISHED
sDebugger finished.
in a part of my code i used QVector:
int logic_points_number=5;
int logic_input_points[16][logic_points_number] ;
QVector<double> x1_1(2*logic_points_number);
QVector<double> y1_1(32*logic_points_number);
x1_position=x1_last_position_logic;//start from last drawn point
for(int logic_channel=0;logic_channel<16;logic_channel++){
for (int i=0;i<logic_points_number ;i++){
if (logic_channel==0)// set x1_1 only for first channel
x1_1[2*i]= x1_position;
y1_1[(2*logic_channel*logic_points_number)+(2*i)]=(16.2-logic_channel)+(0.6*logic_input_points[logic_channel][i]);
if (logic_channel==0){// set x1_1 and x1_position only for first channel
x1_position = x1_position + x1_step_logic;
x1_1[(2*i)+1]= x1_position;
}
y1_1[(2*logic_channel*logic_points_number)+(2*i)+1]=(16.2-logic_channel)+(0.6*logic_input_points[logic_channel][i]);
}
}
x1_last_position_logic= x1_position;//Set new last drawn point
}
in run there is no problem. when i delete the above code, there is no problem in debugger.
there is no helpful answer in google.what i shall to do?
thanks
In my case error code was 'the cdb process terminated unexpectedly (code -805306181)'. Changing debugger from 32 bit app debugger to 64 bit app debugger fixed this issue
I'm trying to serve a big number of small files with G-WAN (version 4.3.14, started with sudo on 64-bit Ubuntu 14.04.3). I start hammering it with requests over a single connection using wget to provide base URL and a file with a list of the URL suffixes. At some point, which is different for different runs, the gwan executable silently exits. There's no trace in the gwan log or in the site error log (I did change '_log' to 'log' to enable logging). The exit status code is 139. What does it mean? When I stop it with Ctrl-C the exit code is 130.
Is there a reference for the exit status codes? I cannot find any with Google.
First, Ubuntu 14.04.3 is very recent while G-WAN v4.3.14 is very old. Almost every new OS release introduces cincompatibilities that require patches and this is why we have to issue more recent releases for registered users. This explains the 'silent exits' that you are experiencing.
Second, process exits codes can be found this way:
./gwan -h
echo $?
0
Zero means no error, and any other value is an error (mixing system flags to be as informative as possible). That's why Ctrl+C returns 130: Control-C is fatal error signal 2, (130 = 128 + 2).