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.
Related
I'm working on a compiler for the CLR, and I mostly have it working. I'm trying to generate debug information, and I can get it to create an embedded PDB in the generated assembly where all the debug metadata looks right. When I load the assembly, the Modules view says "Symbols loaded." But I can't get the debugger to recognize breakpoints, and if I throw an exception inside the code, it says,
Source Not Available
Source information is missing from the debug information for this module.
When I look at the assembly in DotPeek, it does not say "Debug" on the assembly's main name line, the way it does for C# assemblies built with debug information. I'm not sure what's missing, though.
What can cause this error to come up? In case anyone needs a test case to look at, here's one.
EDIT: Please read the question and take note of the Tags. I've gotten a couple different answers on here that are bog-standard "how to get PDBs to load under normal circumstances" answers. This question is not about normal circumstances. I am building the compiler and it is generating incorrect PDBs. I need a way to debug the output of the PDB code that I am generating myself.
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.
Any way to speed this up without losing any of the debugging functionality?
Compared to debugging with clang on mac/linux the generated code is horribly slow.
You could also try to disable debug heap by setting _NO_DEBUG_HEAP=1
See here more information about that:
http://ofekshilon.com/2014/09/20/accelerating-debug-runs-part-1-_no_debug_heap-2/
Find out why it's slow. This is how I find out. My off-the-cuff-probably-wrong guess is it could be in data validation. When you find out what it's doing you can probably turn it off by tweaking some compiler flags.
A way to do that is to make a release configuration, clone it, and then turn on symbol-retention and turn off compile-time optimization.
This way you can debug it, but without turning on all the data structure validation, index checking, debug-new, etc .
This blog post has the full explanation of the OP's solution - referred to in his comment on Nikolay's answer: "I gained alot more back by setting "basic runtime checks" to Default. This got me almost to the speed of clang's debug builds."
This solution still works for the same problem in VS 2015.
I am using VS2010.I was changed my project and its dependent projects .Net Framework to 4.0 from 3.5.Now I could not attach the process,due to this I am not able to debug the code.
I have cleaned all the bin folders and rebuild the projects ,but still I am having following error.
Please help me to resolve this..
I'm not sure what the question is here. The error message clearly tells you that you need to
Turn off (disable) optimizations
Turn on (enable) debug info
Rebuild your project so those changes take effect.
Apparently you only did step #3.
Also see vs2010 debugging module was built without debugging information?, which may provide more information.
I also received this error, and did all the right things as described above - those have been my settings all along anyway. I even went so far as deleting the assembly from the long C:\Users... path in the error message - it still didn't cause that message to go away.
Then I tried putting a breakpoint in the source, which should not be allowed if the module really WAS built without debug information. And then ran the program and it stopped at the break point and I could do all the usual debugging.
So right now I'm just ignoring the message. I could do as suggested and disable the 'Warn if no user code on launch' option as suggested in the message, but I'm not doing that until I can spend some time working out why the message comes up at all.
Uncheck this option in Visual Studio 2012.This would solve this issue
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.