I'm building in debug mode, not release, yet it loses track of variables. See below where the value of nx seems lost, the way you might expect if you were trying to debug an optimized build. Is this a bug in Xcode or am I doing something wrong?
Compilers do sometimes drop debug information for "unused identifiers". Debug information can quickly get huge, so even at -O0 compilers have to do some work to ensure that they don't emit more info than needed. Defining "needed" is trickier said than done, but surely it should keep all local var's and let's.
So it seems to me this one is worth filing a bug on the swift compiler. It's particularly odd that swiftc emits debug information for ny but not nx. Do you use ny more later on in the function?
If you do file a bug please include a buildable .swift file or project that shows the bug.
Related
I find that Swift is quick to mark down changes i make as compiler errors in the side panel, and then when i compile, it decides i am right after all. Is Swift just pessimistic about my code?
Can I get the compiler to wait for me to finish the line before declaring it wrong?
There is nothing pessimistic. Xcode uses the same tool - the compiler - to get the errors. However, it usually compiles only one file, using cached compiled objects for the other files. It also doesn't invoke the compiler after every change in your code, so errors that are already fixed can stay there in the side panel.
Building the project fully forces Xcode to refresh the cache and get the current list of errors from the compiler. I do agree that Xcode has many imperfections and this is one of them. When you can't find an error, just rebuild the project.
Note that IDEs for other languages often rebuild the project automatically to solve such problems. This is currently not an option in Swift because it would take too much time.
I'm using VC10 (but I guess this applies to VC9, VC10 and VC11). In short, I want to compile a release library, ship it and allow users to be able to link to that library when making a debug or release build of their application. Annoyingly I keep getting the LNK4204 error, for example:
mylib.lib(an_object_in_my_lib.obj) : warning LNK4204: '[PATH TO USER APPLICATION INTERMEDIATE DIRECTORY]\vc100.pdb' is missing debugging information for referencing module; linking object as if no debug info
Fine. I understand what this is saying. My initial reaction was "well, it's going to be trivial to turn this off". However I can find no way of preventing this. Things that have surprised me are:
I can't find any option in the library project setting to compile without debug info (even in release!) - and by God I could swear there is a way!
I can't find any option in the user application project settings to instruct the linker that I know there's no debugging info and it should just get on and do what it's told!
Is there any good solution to this? Presumably it's not uncommon to want to link to a library with no debug info but produce debug info for the binary I'm creating? What about linking to kernel libraries and crts, surely that's exactly what happens? I can't believe I've never found this problem before, it seems to obvious (can you tell I'm exasperated!).
FYI, before people say it, I really don't want to ship release libs with debugging info as I want to minimize the risk of reverse engineering. I know that some people will say that you'll regret it when a user gets a bug and you have no pdb info, but trust me when I say I don't care about that.
Update:
I believe I've got around the problem but I'm not entirely sure why it works. Definitely need to look into this some more. But in short, I can (and in fact need to) build with VC9. Note that VC9 actually gives you an extra option of "Disabled" for "Debug Information Format", which doesn't appear in VC10; this may explain some of my confusion.
Now the "solution" seemed to be to create a debug version of the library (I'm fine with that) but keep debug info "Disabled". When I do this I get no complaints. It's quite strange as in both cases there's no debug info (the cases being linking debug to release and debug to debug), however when linking to the debug lib I get no warnings. It's a bit of a mystery so far. If I get time I'll investigate it further. Maybe I'm missing something!
The only way to prevent the warning is to supply symbol info. If you're clever you may be able to supply enough symbol info to satisfy the linker, but not enough to raise your imagined risk of making it easier to reverse engineer your code.
I use ndk-build to compile libpng source code in debug mode, then it shows “internal compiler error” in pngrtran.c. But when I compile in release mode, it can success. Is this a bug in libpng? How I can resolve this?
It's not a bug in libpng; anything a program describes as an "internal error" is a bug in the program (libpng does this, but then it shows "libpng: internal error"!) So it's a bug in the compiler.
You should report it to the ndk guys or you could go directly to the compiler vendor (probably GNU) because they would likely to be more responsive.
You can't resolve the problem - it needs a compiler fix (maybe only to output a message that doesn't claim it's an internal error, but at least that.) You can avoid the problem by simply not compiling libpng in debug mode. Since I assume this is for Android so you can (I believe) mix-and-match debug and now debug code (this does NOT work on Windows with at least one compiler!)
You can also try working out which compiler option reveals the problem; compare the options being passed to the compiler in both release and debug, then bisect the differences to see if you can narrow the issue down to one setting.
John Bowler jbowler 2 acm.org
The android team should know about the bug. As Its a resurface of an old one:
http://code.google.com/p/android/issues/detail?id=20862
I've got a little problem. my application runs without problems in Debug mode, but crashes in release mode. I can't track down the problem, because in release mode all the Debuginfo appears to be nonsense. However - sometimes in other projects the Debug output is also valid in release mode. What projectsettings do I have to change such that the Debug output is valid in release?
thanks!
Even in Release mode "Generate Debug Info" should be set to "Yes" per default. The problem is that when you're running in Release Mode the compiler optimizes the code which makes it hard for the debugger to display the correct values of variables (it may for instance choose to keep some variables in registers etc.).
There's not much to be done about this, you could always turn off optimization either globally or around a specific function using #pragma optimize ("", off) / #pragma optimize ("", on) around it but this essentially means you're running in Debug Mode again and the crash will probably go away...
If you're comfortable with reading assembly code, you can switch over to disassembly mode and through a little investigation find the correct values of your variables.
Likely, you're making use of uninitialized variables.
In your project settings, set
Configuration Properties > C/C++ > General > Debug Information Format
to Program Database
Then, set
Configuration Properties > Linker > Debugging > Generate Debug Info
to Yes
The good old "debugging with traces" approach may help you having a rough idea of where the problem is. Then read this portion of the code again and chase uninitialized variables.
I have a workspace for running an H.263 Video Encoder in a loop for 31 times i.e. the main is executed 31 times to generate 31 different encoded bit streams. This MS Visual Studio 2005 Workspace has all C source files. When i create a "DEBUG" configuration for the workspace and build and execute it, it runs fine, i.e. it generates all the 31 output files as expected.
But when I set the configuration of the workspace to "RELEASE" mdoe, and repeat the process, the encoder crashes at some test case run.
Now to debug this is verified following:
Analyzed the code to see if there was any variable initialization being missed out in every run of the encoder
Checked the various Workspace(Solution) options in both the modes (DEBUG and RELEASE).
There are some obvious differences, but i turned the optimization related options explicitly same in both modes.
But still could not nail the problem and find a fix for that. Any pointers?
-Ajit.
It's hard to say what the problem might be without carefully inspecting the code. However...
One of the differences between debug and release builds is how the function call stack frame is set up. There are certain classes of bad things you can do (like calling a function with the wrong number of arguments) that are not fatal in a debug build but crash horribly in a release build. Perhaps you could try changing the stack frame related options (I forget what they're called, sorry) in the release build to the same as the debug build and see whether that helps.
Another thing might be to enable all the warnings you possibly can, and fix them all.
Could be a concurrency problem of two threads. The DEBUG configuration slows the execution down, so the problem does not occur. But, only a guess.
Interesting problem.. Are you sure you have no conditional compilation code lurking around that is not being compiled in release mode? i.e:
#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif
Thats the only thing I can really think of.. Never experienced anything like this myself..
Can you add the debug symbols to the release build and run it in the debugger to see where and why it crashed?
Yeah, those bastard crashes are the hardest to fix. Fortunatly, there are some steps you can do that will give you clues before you resort to manually looking at the code and hope to find the needle.
When does it crash? At every test? At a specific test? What does that test does that the others don't?
What's the error? If it's an access violation, is there a pattern to where it happens? If the addresses are low, it might mean there is an uninitialised pointer somewhere.
Is the program crashing with Debug configuration but without the debugger attached? If so, it's most likely a thread synchronisation problem as John Smithers pointed out.
Have you tried running the code through an analyser such as Purify? It's slow but it's usually worth the wait.
Try to debug the release configuration anyway. It will only dump assemblies but it can still give you an indication of what happens such as if the code pointer jumps in the middle of garbage or hits a breakpoint in an external library.
Are you on an Intel architecture? If not, watch for memory alignement errors, they hard crash without warning on some architectures and those codec algorithm tend to create those situations a lot since they are overly optimized.
Are you sure there are no precompile directives that, say, ignores some really important code in Release mode but allows them in Debug?
Also, have you implemented any logging that might point out to the precise assembly that's throwing the error?
I would look at the crash in more detail - if it's crashing in a test case, then it sounds pretty easily reproducible, which is usually most of the challenge.
Another thing to consider: in debug mode, the variables are initialized with 0xCCCCCCCC instead of zero. That might have some nasty side effects.