in a very specific C++ environment (an application to analyse CAD-drawings), dbg becomes extremely slow when I try to import large drawings....
In this test environment I integrated GoogleTest/GoogleMock testing framework to manage the test results and extract relevant (debug) data, and do the JNI mocking to be able to test without the Java EE "counterpart" of the application.
For 1 specific drawing the processing is grossly delayed, in another case the dbg application itself seems to be "frozen" indefinitely. It reacts on no signal whatsoever anymore: if you press the "termination" button in the toolbar of the debug console (the "red square"), the message: "Termination Failed" appears. I eventually shut it down by terminating the debug thread.
When I run this "drawing import" WITHOUT debug (so just "run"), all is processed in about 15-20 seconds (and no catatonic behaviour of the environment).
In this configuration, the application runs on Linux (within a VirtualBox within a Windows environment)
....
Question: what could be the case here? I tried to extract some relevant info but dbg gives nothing away. Any bright idea's?
Thank you in advance.
Related
I'm working on debugging a game written in C++ and it recently started hanging on the splash screen when I try to run it in Xcode (in Debug mode). I can't identify any changes in my code that could have caused this, and there aren't any log messages being printed while this hang is happening (something that I know can severely slow down a program). I then opened Instruments and used the time profiler to try and find the source of the problem, but when I ran my program on the time profiler it progressed past the part where it hangs, and ran as expected. Both running and profiling are set to use Debug mode so the build is the same, does anyone know what could possibly cause an issue like this?
More info: I'm using LLVM/Clang as the compiler and LLDB as the debugger. Looking at Activity Monitor during the hang I can see the game is shown as 'not responding' and Xcode is using a lot of CPU activity, despite not printing any log messages etc.. In 'Edit Schemes' the Profile scheme is set to use the Run action's arguments and environment variables.
I'm new to Xcode (and Macs in general) and am trying to port some of my code base over to run on both OS X and iOS. I have a large set of unit tests written against the Google C++ Testing Framework (Google Test). I successfully compiled the framework and I can run some tests, but I'm unsure how to view the colorized output from within Xcode.
I'm used to hitting "Run" in Visual Studio and immediately seeing a console window (with colors) letting me know at a glance if the tests passed or failed.
I've managed to set up a "Run Script" "Build Phase" but that seems to only output to the Log Navigator which obliterates the colors and even the fixed-width output making it very difficult to see at a glance if the tests pass. I also can't find a way to display the log after running the tests. When I do this nothing appears in the "All Output" window.
I've played around with XcodeColors but that doesn't seem to work with scripts that use the ANSI color codes.
At this point I wouldn't be surprised if this simply can't be done within Xcode. That would be ideal, but if it isn't, is it possible to create a "Run Script" that will run the tests in an independent Terminal window? Colors work fine there.
Thanks for any help!
Here are links to a tool that colorizes the text in the Log window. It's free and the source is in github so you can figure out how it works. The first link says that it just uses simple ANSI codes to do the job.
http://deepitpro.com/en/articles/XcodeColors/info
https://github.com/robbiehanson/XcodeColors#readme
To kick off the execution from within Xcode, you will probably need to add a new target to your project. To add a Target, click on your project and then there is an Add Target button on the bottom of the screen. I don't know exactly what you're executing but here are my best guesses based on your question:
MacOSX/Application/Cocoa-AppleScript or Command Line Tool - Create a simple script or program that will execute your units tests.
MacOSX/Other/External Build System - Allows for execution of an external "make" program with args.
Once you have a way to execute your unit tests, you just need to figure out how to route the output from the unit tests to the Log window. If you can edit the Google Test project and make it use NSLog(), that would seem to be the easiest solution. You could create your own logging method, perform the ANSI colorization, and then send the final text to NSLog().
ADDED: OK. Interesting findings... Read all before starting. Here's what to do:
Start AppleScript Editor. This is in LaunchPad. Paste the following script into it:
tell application "Terminal"
activate
do script "<your commands>" in window 1
end tell
You can repeat the "do script" line as needed. Use this to execute your unit tests. In Script Editor, do Save As.../File Format=Script and save it to a safe location for now like your Documents directory. This will create a file like "UnitTests.scpt".
Now go to your iOS project. Select the project at the top-left. Select the Build Phases tab top-middle. Click the Add Build Phase button on the bottom right. Here's the interesting part.
Leave Shell as is ("/bin/sh"). Add one line:
osascript ~/Documents/UnitTests.scpt
That will execute the script after every build.
But here's the interesting part I found. Click on Build Settings (top-middle). Make sure All is selected (not Basic). Scroll down the list to find Unit Testing. Open Test Host. Hit the + next to Debug. You can also put the above osascript command here. You might be able to execute your unit tests here and if you can, the output will likely show up in the Log! Let me know what happens.
I am familiar in Java: JUnit + JCodecoverage, at mobile applications: Android and iPhone I was to lazy to develop with TDD, but if I would like to start than :
I would create a Hello Word app, with JUnitTesting options turned on:
Include Unit Test checked
That will create a Test App / target whatever, and you will be able to run that.
The same thing it is at Android too: you have to create a "test project"
Once I did and forgot how is working, but, there are other stuff too:
- long press the Play button on Xcode ( 4.4 ) and you will have a dropdown menu with: Run, Test, Profile,Analyze.
I can't present those, because if I press the Shift+ Cmd + 4 to screenshot it it is changing, but here it look like the changed menu:
IMHO: for banking, forex, other financial or military (high security software) I would use test driven development, with over 99% code coverage, but those simple 3-4 web-service call mobile apps, which display public data available in browsers are just waste of time to develop tests and upkeep it!
Many times I need to test with internet connection and without.
to be worse case with WI-FI connection , but router doesn't give IP or let go out the phone, but if I ask the phone state: it is connected...
The GUI flow hard to test from unit testing, where is / would be usefully for me: the data got from web-service and synchronization with internal cache. As I see it is still cheaper to do it with manu testing.
I'm going through Qt tutorials on OSX. One thing I noticed is that when I launch the executable (e.g. the push button hello world example), the app will launch as a background window and I have to switch tasks to bring it into the foreground. How can I force the Qt application window to be the foreground window upon execution?
I'd like to do this since it's how most apps behave, not to mention that manually switching tasks slows down my edit-compile-run-debug cycle).
The behavior you observe is due to interaction with the debugger when you start the application under the debugger using ⌘-Y. If you simply run it using ⌘-R, it behaves as you expect. Your application itself is fine.
Starting OS X applications by directly firing up the executable from within the app bundle from the terminal will act similarly to running them using ⌘-Y -- they all start in the background. Qt is probably mimicking whatever magic Finder does when it starts the process via ⌘-R -- said magic may reduce to simply bringing the child app to the foreground. gdb on OS X is not so "clever", and probably for a good reason.
OS X approach is to try harder not to steal focus -- a good thing IMHO.
If you merely want to run the application, not debug it, then modify your launch command to look like open -a '/Users/daj/foo/bar/baz.app', where baz.app is the app bundle folder. Do not append a trailing slash.
If you can coax your debugger to follow through to child processes, then you can of course launch open itself under gdb, and it will work as expected -- with your child application on top.
I have a simple Qt program running on Windows XP - its just a data logging program. It reads any data sent to it on the serial port and then it pushes this to the GUI and logs it to a text file.
The thing is, if I run the program for an hour (roughly, sometimes more) it will hang up on me. The GUI locks out and the program stops logging. On the CPU monitor on the performance tab of my task manager, one of my cores always goes straight to 100% when this crash happens and stays there until I close the hung application.
I have literally no experience in diagnosing problems like this - has anyone got any tips on where to start?
Run the application until it freezes and then attach a debugger. Look through the threads and check where each one of them is. This should give some clues on what's going on. For threads that are stopped within framework code an investigation of the call stack should show if your code is involved.
Make sure that you do this on a debug build with all symbols included to get readable results.
The project my team has been working on has reached a point where we need to deploy it to computers without the development environment (Visual Studio 2005) installed on them. We fixed the dependency issues we had at first, but we're still having issues.
Now, once the installer is finished, our project gets stuck somewhere before entering WinMain. It only takes up 13MB of RAM, but takes up 50% of the cpu cycles.
Are there any suggestions as to how debug this problem?
Edit: Clarification - this is a C++ project.
Is it possible the hang occurs while some global variable is initialized? That happens before WinMain, and from a global variable's constructor any code could be run. Also, take a look at the busy thread's stack using Process Explorer (make sure you deploy the PBD in order to get a meaningful stack trace). The stack trace should make it obvious where is that thread hanging.
You might have to resort to old-time debugging - outputting print statements to a console that refer to what part of the application has been run successfully. Without the IDE installed on the target machine, there really aren't many options for debugging.
If your running vista or windows 7 you can create a memory dump from task manager (right click and select create dump file) and then transfer that to your dev computer, load the symbols and it will show you where the program was at that time.