I am running the Sulley fuzzing tool, which uses pydbg to debug the target process. The pydbg threads are spawned in the process_monitor.py module of the Sulley environment. My problem is that when a test case (malformed packet) causes the process to crash, the debugger thread continues to run, and the following test case triggers an access violation.,This is then sent to the session module saying the wrong packet, the second test case caused the access violation.
I am trying to print the log information from pydbg to debug exactly what is happeneing, but nothing I do seems to be working. Obviously since this a thread it has no console to print to, so I've tried many different methods of writing to a file.
Even a very straight forward
logFile = open('C:\sulley_build\sulley\logFile.txt', 'w')
logFile.write("test")
won't create a file at that location. I know the pydbg thread is spawned, yet even putting that code in the _init__ function does nothing.
Help?
It's been a while since I've worked with the process monitor, but here's my advice:
Sulley had several procmon bugs when I used it. I submitted two patches here:
https://github.com/OpenRCE/sulley/pull/94
https://github.com/OpenRCE/sulley/pull/83
These bug fixes may be related to your issue (hard to tell with Sulley's architecture). I would give them a try. The fixes are already applied on my fork, or you can manually apply them in your own fork.
It sounds like the procmon is not reporting the crash properly. I distinctly remember this issue, but can't recall if the fixes mentioned above resolve it. If you do try to get it working, the key method is ProcessMonitorPedrpcServer.post_send.
If you want to report more crash details, try writing them into self.last_synopsis. See ProcessMonitorPedrpcServer.get_crash_synopsis.
Happy fuzzing!
Related
My visual studio code seems fine and all of the sudden boom its crashed. Searched google for the error code No solution found. Any help would be appreciated.
error code = -536870904
Whenever anything stops working for no apparent reason then think:
Did it work before?
No, it is new or it has not worked yet.
Check your download, ensure it is compatible with your operating system and other running programs.
Yes, it used to work, but now it doesn't.
Look at the next step
Did you recently update the program, your operating system or any other programs?
Yes, I updated something.
Try rolling back your updates to see if it works again. New versions of software tend to be more error prone than the older, established versions.
No, I don't think I changed anything.
Either you are unaware of changes made to your system or some subscription has ran out. At this phase, the best option is to use common sense or uninstall and reinstall.
Another issue that you might be having is if you're running too many programs at once and your computer is force closing programs to protect itself. Try monitoring your Task Manager you may see a spike right before the crash. Also, make sure the crash isn't caused because of trying to run code (especially with code that has infinite loops)
I have encountered a critical issue that Unity Editor freezes. I've spent many hours debugging step by step of my codes but still can't find where the problem is. So I think maybe I should try thinking from another angle, generally speaking what reasons would cause Unity Editor freezes and not responding?
I can't find a general case discussion about this topic.
From my experience, infinite loop is one reason for sure. Deadlock is critical issue, but not sure if it causes Unity Editor freezes. Unity Editor bug that I encountered only makes the whole editor crashes, instead of freezing. Any other experiences are welcomed. Thank you!
In such case, what kind of tools or methods could I use to debug it? Right now since the editor freezes I can't use "print" to find out what happens after it freezes. So I use Visual studio to debug the Editor thread, in this way I can see all the prints that I wrote. It appears the game is still running, only the editor not responding. And I can use VS click "attach to Unity and play" and put some debugging points, then debug step by step.
The first thing that I would check out is for an infinite loop. At the hang/freeze moment, you can attatch the debugger of your choice and pause the execution. In the case that it is an infinite loop that it is executing, at the exec time pause you might find the execution in a forever running while (true) {...}
Other thing that I would check is the plugins in use. Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and hang. Source
To check that you can check the active threads in the visual studio command window af the freeze is reproduced:
View->OtherWindows->CommandWindow and type in this command:
Debug.ListCallStack /AllThreads /ShowExternalCode
In the stack you can check if some thread is there with no need, or if its related with the plugins mentioned above.
Also an interesting point is to check in the windows task manager (in the case that you are using windows) if the CPU usage is to 0%. It can lead you to the type of hang that is taking place.
Good luck.
Edit: I forgot to mention, you need to check also the unity logfiles
I notice this all the time, and its super frustrating.
Unfortunately, this could be any number of issues. I notice this issue most often when working in projects that are made for the Universal Windows Platform.
Try using the Task manager to monitor specific processes / threads running.
Some follow up questions:
What platform is your project currently targeting?
What version of Unity are you running? Have you tried other versions?
What are your computers specs? Is the OS up to date? Graphics Drivers?
Does it happen (or happen more often) when an external code editor is open? Perhaps try going to Preferences>External Editor > Regenerate Project files.
Are you using Unity Collab by chance? I've had issues where collab is stuck trying to communicate with Unity Servers / looking for changes. Try logging out of your Unity account through the editor, and log back in.
Have you tried looking for a Unity editor crash dump, or error log files? I think they can be found here C:\Users\username\AppData\LocalLow\Unity by default. Those files may give you more specific data concerning your problem.
Unity's new versions are getting more slower and slower. From my experience 2019 versions are the best and more stable.
I solved my issue. It's fundamentally an infinite loop.
It's not a simple case such as "while(true)". I'll try to explain.
My game was a PvP game, and I'm making a local AI. Usually my design pattern works fine, however I just turned off the simulation of "AI thinking time", and since the AI codes and server codes all run in local mode, the transmitting of data between server and client are replaced by local method call(meaning instantly executed before everything else).
There is a loophole in my server code. I use "Update" and a flag on server to change a specific game state, however in this particular case, it got into an infinite loop because the local method call is executed before the "Update". And because my AI now doesn't need real time to "think", it "acts" and transmits the event data to server right away. And since the transmitting doesn't need time any more, it calls the server method instantly, hence forming the infinite loop.
When running my code in debug mode, I keep getting 2 error messages:
Could not delete [path_to]\productiondb.log. May be locked by another process
I don't know what process might be locking it. It comes when I make changes to the code while my Pivotal tc Server is running in debug mode, but it dosent seem to create a lot's of trouble. Sometimes however, I get this warning:
Also due to some changes. I usally just restart the server and move on. This isen't the real problem, the real problem is that I get these messages when I havent doen any changes. Somethimes it accures when I run a certen part of the code, other times i occurs when I open certen codes in sts, however, it doen't seem to stop at the same place twice.
I am suspecting that this has something to do with git. I am using git to change between versions and doing tests. So I am thinking that STS has some of the code in memory from before I changed branche with git, and isen't updating it before I run or open the file with that code. But I am rather new to both sts and git, and can't be certan that it would work that way. If it is, does anyone know how to update sts after I have changed branch? If it is not, does anyone know what might causing it?
If you run an app in debug mode, the Eclipse Debugger tells the application when code gets changed and tries to use the debug API to swap in the new code into the running application. This is especially useful if you debug your code, hit a breakpoint, step through the code, fit the issue, change the code, and press save. At that moment, the Eclipse compiler updates the class file and tells the running JVM to swap in the new code. If that succeeds, the debugger will jump back to the last stack frame and the execution of your app will continue with the beginning of the method that you entered. This allows you to directly continue to debug and step through the updated code without restarting the app.
While this is a great feature of the JVM, it is very limited in terms of what scope of changes to the classes the JVM can deal with while doing this hot-swap. It is usually limited to method implementations. So adding new methods, adding or deleting members of the class, etc, are not supported. As a result, the above screenshot will appear. It means that the JVM wasn't able to hot-swap the changed code and will continue to run with the previously loaded code instead of the changed one.
I've got some conditions where I need my frameworks to report a fatalError or a preconditionFailure and crash. I have set up some unit tests around these conditions to make sure they hit correctly.
It works really well if the unit tests are run without a Test Host application, but the moment a Test Host application is involved, any fatalError or preconditionFailure hits an automatic XCode break with the message Thread 1: Fatal error: <CUSTOM ERROR HERE>. and stops the execution of the rest of the tests until I press the Continue program execution button manually.
This is obviously an issue because I can't just let my tests run in the background and I need to be actively hitting the Continue button every time one of these tests hits which is quite annoying.
Is there any way to disable this XCode break?
Looks like this is fixed in Nimble 7.1.3, a library which I use to test these particular cases. I also found this specific issue in the Nimble library issue 478 which has a comment on a workaround you can use to disable the debug executable when running you tests. Hopefully this helps anyone else stuck with the same problem I had.
I have have a mod_perl program that implements its own handler function (i.e. it's not using Apache::Registry).
I have a parser module written using Parse::RecDescent.
I have been successfully using the parser module in another similar mod_perl program for months with no issue.
Simply "use"ing the parser module in the my new mod_perl program (i.e. no references to functions in the module) causes the Apache server to spawn child processes until it hits it's max limit. Commenting out the "use" statement solves the problem (but leaves me without the use of the parser, obviously).
I suspect that the inclusion of the library is doing something that causes the Apache lifecycle to hang before it ends. I believe this is happening after the logging phase since the response is sent and the log is updated.
Anyone have any clues for me? I'm at a loss.
--phil--
I don't have an answer for you (personally, I use fastcgi...) but I can suggest an approach: attach strace, ltrace, gdb, etc. to the apache child process and see where its hanging. You may need to rebuild apache, mod_perl, and even perl with debug symbols to get reasonable output from gdb.
So, I solved the problem, but don't understand why it worked. That leaves me slightly frustrated, but I'm grateful that the problem's gone.
Before I took derobert's suggestion and traced the process, I decided to move the library load to the mod_perl startup file and voila, problem solved.
Interesting that it took me a day of work to get to the point where I understood the problem enough to ask the question on SO and then once I got to that point, a simple thing solved it.