I recently switched to Ocaml 4.03.0 (installed using Opam) and started seeing erratic behaviors from ocamldebug on examples that previously went through without any problem.
In specific, I load up the byte code into ocamldebug, set arguments and run it. I don't set any breakpoints, I just want the debugger to hit an assert failure that both byte code (outside the debugger) and native code hit. Instead of reaching the assert, ocamldebug stops after running for a while saying
Lost connection to process 1234 (active process)
between time x and y.
Segmentation fault (core dumped).
Restart from time z to get closer of the problem? (y or n)".
If I try to get closer the problem by saying "n" then running again, this problem keeps repeating.
Apart from minor changes to my code (like additional print statements) nothing has changed in my set up except the Ocaml version. A collaborator of mine also has this problem, both with Ocaml 3.12.0 (installed from sources) and 4.03.0 (installed from Opam).
Why is this happening? And is there fix to this? Any insight into this is much appreciated. Thanks!
Related
I wrote a program about a month ago, and it worked fine. I haven't touched it since than, until today.
All of a sudden, I get the warning when opening Pycharm: "PyCharm has failed to load the environment from '/bin/zsh'. Integration with tools that rely on environment variables may work incorrectly." I couldn't find a good explanation and solution to this warning, without leaning out of my comfort zone of altering files on my computer.
When running the program I got the error message "Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)". I have read that this error is related to a memory problem or, that a file needs to be closed.
I have cleaned the memory of my mac so far I know how to and all files are closed. The program reads from one file, but this is only one line, which has worked before and I don´t see how this could cause the error. Otherwise, I did write few other scripts in the same project over the last month, but that shouldn't be a cause of a memory issue, right?
Restarting Pycharm and my computer didn´t change anything.
The only other thing I can think of is, that I have updated my mac to Monterey version 12.2.1.
Could that be the cause for this behaviour? Did anyone else have a similar experience after this update?
And is it possible for the error message and Pycharms warning to be related?
I am thankful for any tip, that may help me understand this behaviour.
I was able to fix this issue through the following steps:
Updating PyCharm to the latest version
Within PyCharm going to File -> Invalidate Caches -> Checking all boxes -> Clicking "Invalidate and Restart"
(Previous attempts to Invalidate Caches with only the default boxes checked did not work for me, but checking all the boxes fixed the issue.)
I'm executing an arm elf (zephyr os + tfm) on qemu and make it run some tests.
Unfortunately, it stops at a certain point without either an error message or warnings.
I also tried with GDB, but at a certain point, it just stops.
It always stops at the same point for the same version (if I add some debug prints it stop earlier or later).
I think there is some pending interrupt that simply is not caught... no idea honestly.
Thus, my question: How to find out the cause of hanging software?
Or also, how can I check which interrupt has been risen to stop the normal execution?
For future reference TF-M has an option to enable an exception info dump print in case of faults. I would start enabling that by setting the following define in the cmake config step: -DTFM_EXCEPTION_INFO_DUMP=True
I have recently been having a problem which essentially makes debugging Go using delve next to impossible. Basically I can't use breakpoints otherwise there is a good chance the debugged code freezes and all I can do is stop the debugger an restart.
To start at the beginning... I have had an intermittent problem debugging Go using GoLand IDE (2019.1) and delve (1.0.0-rc2) for some time. The whole session would freeze - I know that nothing is happening because the debugged process CPU usage is zero, and the fact that there are no messages being written to the log (I have many go-routines most of which are writing occasional log messages). It's as if a breakpoint was hit but the debugger commands (STEP, etc) are not enabled which indicates that the debugger is not at a breakpoint. When this happens I have to hit the GoLand STOP button twice to get the debugger to terminate and then start all over again.
Recently this problem has become far more common. From perhaps a few times a day to almost every debug session. This is annoying but at least it has allowed me to track down what I believe is the underlying problem. It seems that sometimes when a breakpoint is encountered the debugger stops but delve or the IDE does not realise that - so there is no way to continue.
How do I know this? I proved this to myself by setting a breakpoint on a log line (ie, log.Printf). When the breakpoint is on that line (and I know it will be hit) then the debug session freezes. If I ensure there are no breakpoints that will be hit then the program runs absolutely fine including printing the log line. If I set the (one and only) breakpoint on the line after log line the log line is printed and the session freezes.
I think this is a problem with delve. Note that I have loaded the same project into VSCode and the exactly the same thing happens (GoLand and VSCode use the same version of delve), so I don't think GoLand is doing anything wrong. But if someone has another explanation I welcome it.
I have tried a lot of things to track down the cause. I have created a small project in order to demonstrate the problem but it does not occur in a simple project. It appears that I am doing something wrong (in my large project) that causes delve to misbehave but I have no idea what that is.
First, 1.0.0-rc2 seems anvient forn Delve: the current version is 1.2.0
1.0.0-rc2 is so ancient that a similar bug was reported in August 2018 (issue 1318) regarding an headless execution of delve:
dlv debug --headless ...
Adding --log --log-output=rpc can give you additional clues.
dlv debug --headless --listen=:2345 --api-version=2 --log --log-output=rpc ./test.go
Delve itself, in headless mode, will ignore SIGINT.
To stop the headless instance you have to connect to it and then terminate the connection.
To send a SIGINT to the target program you have to start the target program, which you didn't, because to start the target program you have to connect to delve first.
I've developed a software using National Instruments LabWindows/CVI and installed the .exe in a Windows 7 32 bit PC with 4GB RAM.
When I run my software, sometimes I get the following error.
"A program caused the program to stop working correctly. Windows will close the program and notify you if a solution is available"
This is very random and sometimes this error never comes.
Can anyone help me to understand this issue please. I've reviewed my software code many times and I am sure that I am not doing anything wrong in the software which causes this error to come up.
Is this anything related to windows and how can I resolve this? Help is much appreciated.
Thanks
Sujith Rajan
I have encountered similar problems several times.
This may happen even with simple programs like a console application used to get input from user and display some data on screen after processing it.
Usually, this is an indication that your computer is unable to provide enough resources to this program or that there is a bug in your code.
It might be random due to the following reasons:
The Processor might already be busy with several demanding tasks and your program needs to be closed due to this. At other times, when it works well, the resources might be available.
Your program might have a certain logical error that appears at runtime only when certain conditions are fulfilled. (such as an erroneous conditional statement)
Your program might have an infinite loop.
Windows suspects your file to be harmful to the system (for some reason).
There are youtube videos that tell you to go set DATA EXECUTION PROTECTION to resolve. This is a red herring. Its also potentially harmful, especially if you are running old dos apps (because you have to for some reason).
If the program throws a unhandled exception , of any sort , you will get this error message.
If you launched it with this code paragraph...
Dim psi As New ProcessStartInfo(pathToTarget)
Dim p As Process = Process.Start(psi)
Dim bIfinished As Boolean = p.WaitForExit(itimeout)
If bIfinished = False Then
p.Kill()
End If
iretVal = p.ExitCode
pathToTarget is the full path to your target exe/bat (TARGET) file
timeout is an integer that represents milliseconds. 2 minutes would be 2*60*1000
bfinished will be true if the program ended by itself. NOTE- this is not the return code. If it failed to finish in (2 minutes in this example) bFinished will be false.
p.ExitCode can be checked to see what the TARGET returned. Typically a 0 is success and anything else is an error code.
This is the message box mentioned by OP, (autoAging happens to be the exe I used to demonstrate this) . It also says 'XYZ has stopped working'. Google needs to know that!
Note that code will continue running in YOUR app so you can do clean up if you like. Clicking or not clicking "Close Program" has no effect on HOST that I have been able to tell.
If you own the code to the TARGET, make sure you handle all errors and return an appropriate code. That way your calling app (HOST) can know how to react.
You also avoid this msgbox.
If you don't own the code to TARGET, you just have to do the best you can. If there is some output you can readily check, do that. Otherwise I'd assume failure and proceed on that assumption.
This message box does consume resources. Although its not a huge issue, enough of them will run your box out of memory.
There is unix-socket server written on PHP (but I don't think it has something to with it). Client side is written on c++ and based on boost::asio library. When I launch program normally - everything works fine, except one (not related to socket communication) bug that I obviously want to debug. But when I start step-by-step debugging it I immediately receive 'Broken Pipe' error on the steps which perform write operations on sockets. If breakpoint is set up after socket write operation - everything work fine until the next attempt to step over the write func.
Spent whole day trying to solve this problem, but unsuccessfully...
Had anyone met the same trouble?
using GDB bundled with xCode 3.2.5 (64-bit) under OS X 10.6.7
GDB uses signals aggressively. If you want to install signal handlers, check out the following example:
https://github.com/sean-/Boost.Examples/blob/master/asio/timer/timer.cc#L106