I make some C-style functions in WP8 C++ runtime component. Every function take ponters for const input and output arrays. Debug version work great, but in Release some functions works wrong. The magic consist in simple thing: this functions have the same interface and works with pointers in the same way, but some functions work correct and other functions work wrong.
Which are standart problem exists with switching from Debug to Release in WP8 SDK Visual Studio 2012?
The problems are the same as any other C/C++ Debug/Release build configuration - the exact issues will depend on your Debug/Release settings and what your code does.
Typically:
the optimizer will move code and data around and/or remove code.
Release code will also typically run faster due to the optimizer, so you will notice changes due to race-conditions.
You will need to get used to debugging in Release configuration on a real device. Getting the same code to run on the Emulator reliably will also help you with some race conditions too (as the x86 Emulator is faster than the ARM devices).
See "Release /Debug hell, with V-studio C++ project", "Separate 'debug' and 'release' builds?".
Related
I can't figure out how a desktop environment developer test his code. Usually, a C or C++ programmer compiles his code an then run it (i'm not one of those programmers, i'm a web one).
So, you usually build your gui application over some kind of desktop environment (windows, mac os x, gnome, kde, xfce...), sow how they build and test their gui desktop?
And if this is a silly question, how does a kernel programmer test his code? for example linux kernel? how do you know that what you just wrote works?
Testing is a very broad term there are many types (partial list):
unit tests - test small pieces of code. test that the code behaves as expected.
system tests - test whole application in real world scenarios.
performance tests - test what is the performance of the application or part of it.
GUI testing - test operation of GUI elements (not so common as automated tests)
static analysis - compiler warnings on steroids
dynamic analysis - at a minimum memory checks - check mem allocations and usage
coverage tests - check that all code is executed.
formal verification tests (very advanced) - e.g. check when assertions/assumptions are broken.
Kernel code can be debugged by connecting using a 2nd computer (host). Virtual machines uses the same principal and simplify the setup but can't always work as HW might not exist in the guest VM.
The kernel (all OSes) has trace mechanism(s) for printing progress/problems. In Linux the simple trace is shown via the dmesg command (prints a cyclic buffer).
User mode code can easily be stopped and debugged via a debugger.
Desktop Environments
Testing Desktop Environments in real world scenarios can be kind of annoying, so the developer would have to watch out for every small error he makes, if he doesn't, he will have a hard time developing the DE.
As stated by #egur, there are multiple ways of testing his code, the easiest one and most important (but cannot be used in some cases, of course), he can test that code in a simplified program.
A Desktop Environment consists of many parts, however, in your case, I suppose you're talking about the session manager (or window manager) which is responsible for almost everything. So, if he were to test that, he would simply exit his current DE and use the new executable. In case of some error, he can always keep a backup of the old executable or fix the faulty code using some commandline text editor (like vim, or nano).
Kernel
It's quite hard to test, some kernel developers just write some code and make sure it's fine and compiles, then simply let his users test (by ACK'ing the code, etc.), then it can be submitted into the kernel code. Reasoning behind that is, the developer may not have the hardware needed to test the code.
Right now, you can compile and run the kernel in usermode (UML) if you have heard of it, so some developers may go for it. However, some developers may also want to test it themselves (They of course back up the current kernel incase of a screw up).
The way to test a desktop application is related to the way of control the application unassisted or remotely.
The Cross Platform GUI Test Automation tool (I don't know if this project has a web) project helps you to chose the interfaces/libraries required to solve the problem.
In Linux[1] uses the accessibility libraries to control the application, you have Cobra[2] for Windows and PyATOM[3] for MacOS, but I don't know what kind of technology uses in this platforms.
http://ldtp.freedesktop.org/wiki/
https://github.com/ldtp/cobra
https://github.com/pyatom/pyatom
I'm debugging a program written in plain C (no C++, MFC, .NET, etc.) to the WIN32API. It must compile in both VS2005 (to run under Win 2K/XP) and VS2010 (to run under Win7.) I've been unable to duplicate a bug that my customer seems able to duplicate fairly reliably, so I'm looking for ways to have my program "debug itself" as-it-were. It is monitoring all of the key values that are changing, but what I'd really like to see is a stack dump when a value changes. Oh, I cannot run a "true" debug build (using the debug libraries) without installing the compiler on the customer's machine and that is not an option, so this must be built into my release build.
Is there any way to do this other than just adding my own function entry/exit calls to my own stack monitor? I'd especially like to be able to set a hardware breakpoint when a specific memory address changes unexpectedly (so I'd need to be able to disable/enable it around the few EXPECTED change locations.) Is this possible? In a Windows program?
I'd prefer something that doesn't require changing several thousand lines of code, if possible. And yes, I'm very underprivileged when it comes to development tools -- I consider myself lucky to have a pro version of the Visual Studio IDEs.
--edit--
In addition to the excellent answers provided below, I've found some info about using hardware breakpoints in your own code at http://www.codereversing.com/blog/?p=76. I think it was written with the idea of hacking other programs, but it looks like it might work find for my needs, allowing me to create a mini dump when an unexpected location writes to a variable. That would be cool and really useful, especially if I can generalize it. Thanks for the answers, now I'm off to see what I can create using all this new information!
You can use MiniDumpWriteDump function which creates a dump, which can be used for post-mortem debugging. In the case application crashes, you can call MiniDumpWriteDump from unhandled exception handler set by SetUnhandledExceptionFilter. If the bug you are talking about is not crash, you can call MiniDumpWriteDump from any place of the program, when some unexpected situation is detected. More about crash dumps and post-mortem debugging here: http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu
The main idea in this technique is that mini dump files produced on a client site are sent to developer, they can be debugged - threads, stack and variables information is available (with obvious restrictions caused by code optimizations).
There are a bunch of Win32 functions in dbghelp32.dll that can be used to produce a stack trace for a given thread: for an example of this see this code.
You can also look up the StackWalk64() and related functions on MSDN.
To get useful information out, you should turn on PDB file generation in the compiler for your release build: if you set up your installer so that on the customer's computer the PDB files are in the same place as the DLL, then you can get an intelligible stack trace out with function names, etc. Without that, you'll just get DLL names and hex addresses for functions.
I'm not sure how practical it would be to set up hardware breakpoints: you could write some sort of debugger that uses the Win32 debugging API, but that's probably more trouble than its worth.
If you can add limited instrumentation to raise an identifiable exception when the symptom recurs, you can use Process Dumper to generate a full process dump on any instance of that exception.
I find I cite this tool very frequently, it's a real godsend for hard-to-debug production problems but seems little-known.
The title is fairly self explanatory... isn't anywhere to be found in the version I have (the latest), and all searches on the web have turned up little to nothing in the way of real solutions. There is only a pdf file which explains that omp flags must be marked in the C compiler I use, but I can't even get that far because I can't find the library anywhere!
Is there just a way to pull the library from somewhere and load it in? Or do I need an entirely new gcc file for my IDE to pull from, and if so, where do I get it?
EDIT: Still no luck searching. I'm also willing to work with a different IDE similar to NetBeans... preferably one that uses the Cygwin compiler set as well. If anyone has any suggestions on what I could use that would support OMP, I would be more than willing to entertain them.
Oracle Solaris Studio on Solaris (SPARC and x86) and Linux (x86) provides an IDE with C/C++/Fortran compilers with OpenMP 3.0 enabled, and a debugger and performance analyzer that understand OpenMP.
http://www.oracle.com/technetwork/server-storage/solarisstudio/index.html
And, it's a free download and free to use.
When I link to the one under Release/ ,got a fatal error:
LINK : fatal error LNK1146: no argument specified with option '/machine:'
Then I tried to link to the .lib under Debug/ and this time it works.
But what can be different?
Usually, no optimization is done to debug assemblies, while release assemblies are optimized. Debug assemblies will also often contain cruft like source file line numbers.
This isn't actually a C question; it relates to the platforms used.
Frequently, a project/solution will be set up to create a version for debugging and one for release, and putting them in Debug/ and Release/ directories is a common way to distinguish. The debug version will typically compile fast and run slowly, and contain information to link the internal execution to the source code (such as line numbers and variable names). The release version is typically slower to compile and faster to run, and it's much more difficult to track what's going on inside.
Obviously, there have to be differences between the debug and release versions, if only the appropriate compiler flags. However, in the build systems I'm familiar with, it's possible to make arbitrary other changes, and sometimes this will cause a release-version-only bug, which is a pain. Alternately, if the C code doesn't specify the behavior properly, the debug and release versions might interpret it differently, and that's also a pain.
In this case, I'd guess that there was a difference in how they were built. I can't really comment further without more information.
What is the OS? What is the C compiler used? What build system do you use (if you're using an IDE, possibly the one standard with the IDE)? What is the library you're using. Does your organization build it, or do you get it from outside? Knowing these things would give us a clue as to where to start looking.
You may want to change the build configuration for debug and release versions seperately.
I just built an updated version of SDL.dll, an open-source C DLL that my Delphi project uses, with the Express edition of Visual C++ 2005. I dropped it in the folder with my EXE and tried to run it, but it won't load:
The procedure entry point SDL_RWFromFP could not be located in the dynamic
link library SDL.dll.
Now C never was my strong point, but I remember enough of it from college to try and track this one down. I went poking around in the source code to see what had happened to this function, and I found it grayed out, beneath a preprocessor directive:
#ifdef HAVE_STDIO_H
IIRC, STDIO is the standard C I/O library. I assume this means that it's not available. Anyone know why that would be and how to fix it? Is this a Visual C++ issue or an SDL one?
Most often in the Unix/Linux world, names like HAVE_STDIO_H indicate that the code has been 'autoconfiscated' (which is the official term used to describe the state of having been made to work with the 'autotools' such as 'autoconf'). In such a set up, the configure process would determine whether <stdio.h> was available and would set #define HAVE_STDIO_H 1 in the config.h file that it generates. The compilation would then discover that the platform has <stdio.h> and would compile the matching code (the stuff that is currently greyed out).
Adapting to your Windows environment, somewhat less than 100% confidently since there could be some other significance to HAVE_STDIO_H on Windows, you might decide that it would be OK to include -DHAVE_STDIO_H in the command line options when you run the compiler. Or you might create the config file by hand, and define -DHAVE_CONFIG_H (which is the normal way to indicate that configuration settings are in the file 'config.h'). In the 'config.h' file, you'd have #define HAVE_STDIO_H 1 as mentioned above.
Note: on Unix, you normally find a shell script called 'configure' which you run to create the config.h file. If you have Cygwin, there's an outside chance that you can use that script on Windows - I've just checked that an autoconfiscated package I created on Solaris was configurable on Windows under Cygwin and it mostly worked - all except some network handling. I'd not guarantee that it will always fail (but it's software - guaranteeing anything is pretty dangerous). I should add that the problem is in my auto-configuration code (the tests for the network functionality clearly aren't quite correct), and not in Cygwin per se. If I'd done the job properly, it would have worked. (Someone said "There is no portable code; there is only code that has been ported". That applies here.)
You do need a good simulation of a Unix environment. MingW might also work.
What do the preprocessor directives above it do?
Most likely, this is simply for determining some properties of your compiler, and it's greyed out because whatever the macro signifies, does not apply to your compiler.
Your problem is most likely elsewhere.
Since it can't find the function SDL_RWFromFP, you should probably see if that function is for some reason disabled by a preprocessor directive as well.
However, my guess is that the function exists, but does not get marked as __declspec( dllexport )
Without that, it won't get exposed so programs loading the DLL can call it. Most likely you have to #define something to specify that you want to create a DLL, which will enable the necessary preprocessor magic to insert the dllexport part in front of the function.
Normally, you should not have to add any HAVE_STDIO_H: those are not meant to be public anyway (although sadly many projects pollute the public namespace with those).
I would guess you did not build SDL correctly - or that Visual studio 2005 is not well supported by SDL (I don't know much about SDL, so those are really wild guesses without much information). Is there any test suite for SDL, such as you can test the built dll ?