I was testing whether I could rely on __LINE__ to always return the correct value and created a large source file with many lines.
At some point, the inline function names (which get names like fun#7564-1, where 7564 is the line number) started counting from zero again.
After some research I noticed that:
If your source code hits line 65536, any errors, messages, stacktraces start counting from zero
__LINE__ still returns the correct value
Decorated names of inline functions start from zero again
Compile time errors underline totally unrelated lines
Stepping through with debugging goes over totally unrelated lines
Setting a breakpoint on the actual line sets it on the "blind" line
Tooltips over variables during debugging still show the correct value, and no tooltips appear in the "blind" spot.
To illustrate, with a bunch of newlines and the method being debugged being over line 65535, I managed to get a blind source stepping experience:
Is this 216 boundary deliberate or by accident? Is it a limit artificially imposed by F# or by the CLR or PDB format?
Note (1): I only tested this with F# 4.0, .NET 4.5 on Windows 7 and 2012, using VS 2015.
Note (2): I doubt this boundary will be hit often, unless perhaps for auto-generated source files (in C# I have some autogen'ed files that exceed this boundary).
Update: reported as a bug to the FSharp team on Github here.
I have tried to reproduce using large files, and this is also weird on my machine.
In the GitHub repo, Don Syme has replied and asked something about your source code. This might be a limitation of current Visual F#'s tool.
This appears to be a confirmed bug in Visual F#, the bug report has a full repro solution for download.
There's a related issue on large source files throwing StackOverflowException in Debug build, and another related issue also throwing an SOE on large lambda or entrypoint, but in any build.
Related
I am trying to profile my c++ dll, but the profiler is not working with me. I would like to see the call tree an so on, but only the stl functions show up, and not all disjoint - when i click on any function, their caller is "[broken]".
I don't know if my google skills are just not sufficient, but i can not find any information on what [broken] means, and how to fix it.
This is a debug build. I cannot guarantee this is not due to some compiler settings, but i fell like i have tried everything.
It should be noted that breaking the code and adding breakpoints works fine, so the profiler just doesn't access this information
If it adds any information, profiling the specific DLL as specified here gives the exception "File contains no data buffers".
My guess is that something wrong with PDBs of your output (for instance, you may have /DEBUG:FASTLINK set in your linker's settings, which produces reference-only PDBs).
If it's not the case, you may try my profiler - it works as an extension to VisualStudio, is instrumenting (meaning it's function-accurate) and displays stats in realtime.
I like having a high level of warnings (usually W4). However, with a warning level of 4 or higher, I get a lot of warnings from Windows headers and from third party headers, which makes it very difficult to find the ones I can actually do something about.
Hence my question: Can I tell Visual Studio to show warnings only for those files which belong to my current project?
This would be especially useful when running code analysis. Why show all those warnings for code that I don't own?
I found one thing that might help:
Right click anywhere on one of the rows in the Error List and click Grouping->Path. The path to the file will show up on the left. Now you can collapse all the paths to code that you want to ignore.
It's not ideal, but it's better than nothing.
I've ran into a problem during the C/C++ build using Eclipse/CDT for a project containing many source files - during the linking phase a very long command line is created that is then passed to CreateProcess Windows API function. This command is in format of: {compiler} {flags} path/to/file1.o path/to/file2.o path/to/file3.o [...] and essentially contains all object files created during compilation and in my case is over 34K characters long.
Now historically this has already been looked at, but in my feeling the problem was only raised to a higher character limit. In particular, when looking here it is mentioned there was a problem with 8192 character limit, which seems to be the case when the command was directly passed to command line. The change which attempted to fix it was to use CreateProcess WINAPI function instead, which has a higher limitation of 32767 characters (limits depend on version of Windows used). In case of the project I'm working with, neither limit is high enough, as I've already reached over 34K characters for that particular command.
I've mentioned GNU ARM Elipse as this is what I'm working with, however this is a general issue with the CDT itself and it seems to also be a problem in other IDEs - for example I've read the same kind of reports from Netbeans users. Because I work with embedded systems and there are tools already integrated with Eclipse, moving to another IDE isn't an option.
As for the actual solution - the ideal situation to me would be to have the list of object files passed through a temporary file, as the character limitation is completely bypassed this way. So far I'm using CTD's makefile generator, as it is integrated with the IDE itself (flags, build exclusions etc.), however it isn't configurable in any way or at least none that I'm aware of that would solve my issue.
What are my options here? If it's necessary I might look into the makefile generator itself and modify it to output to file, however I'd rather avoid doing so if it's not the last possible option.
I'm debugging a problem at present in Windbg from a dump. I've got the correct pdbs and I can view the locals etc quite happily. However, the source code I have (which I've pulled from the VCS branch from which this release supposedly came from) appears to be off by several lines in some parts of the stack I'm looking at. I've seen instances where it's off by 1 before, but not 3/4 lines.
What causes this? Is there any definitive way I can check that I've got the right source files?
Are you looking at debug or non optimised version of release code?
Code optimisation may cause the line shift you are seeing so you should recompile with /Od C++ optimization set to 'disabled' and see if this corrects what you see.
WinDbg uses the same method as Visual Studio to check if the source file you are viewing/setting breakpoints with matches the pdbs so it should warn you (I think it does this I cannot verify).
Besides you can verify the pdbs if not the source files using:
!itoldyouso myDLL
additionally you can open the source file in another window, during stepping and it should put a magenta line at the line it thinks the current call is at, this should be correct and behave the same as visual studio.
I'm sort of conceptually designing a plug-in I'd love to have here. What I'd want is to be a able to tag line in my code (something like how breakpoints are added) and then get a trace log of when execution runs though them. Rather than set breakpoints (because they don't work outside the debugger), I'd rather that inside the compiler, the extra logging be added so the AST.
The main point would be to compare different runs of a program; it crashes if I do A but not if I do B and most of the code should be the same so where is it diverging?
Right now I'm doing this with file IO and a diff tool; it works but is a bit clumsy.
I guess the question is: Could this be done and has something like this been done?
I don't know of anything that exactly fits your description. However...
For debugging-only use, Visual Studio 2010 has "tracepoints". These are added in the same way as breakpoints, but rather than stopping the program, they output some text to the debug output. Because they're set in the debugger, they don't affect your source code at all.
If you want to trace activity in a release build, then just add System.Diagnostic.Trace.WriteLine() calls into your code. These can be controlled using TraceSwitches, so they can be disabled by default and only turned on if you need extra information to diagnose a problem. Unlike Debug.WriteLine() calls they are included (by default) in release builds as well as debug builds. Note that these trace calls do cost a small overhead even if the traceswitch is disabled, so avoid using them in performance critical regions of your code.