Does anyone have a clue what could cause a breakpoint not to show the actual place of the code in a specific file?
This is the second time this has happened to me.. maybe someone could help, my parameters:
I am working in visual studio 2010.
This one specifically is a static lib but it also happened to me inside dll's.
The PDB's are generated in Z7, although this has also happened to me in the default pdb generation.
I am sure the code is compiled with the correct lib(also happened in dlls so..)
Also I have some Doxygen comments I first suspected causing this problem(could it be?)
Attached is an image that show where the breakpoint arrow is compared to the callstack of where it ACTUALLY is..
Thanks!
If you debug code that has optimization enabled, the method might just be inlined. This is at least one proven source of breakpoints not pointing to the right position.
One of the scenario's which I have generally noticed is when source file changes due to fetch of a file from source control while debugging. Break point uses the line number of older code.
So, apparently the visual studio text editor doesn't adapt well to CR..
I found that the file had some CR (and not CRLF) and that confused the compiler all together..
When I actually made a compile error on purpose, it didn't even point to the correct line...
So I added LineFeeds(LF) after every CR and it compiles fine...
(Used notepad++ to detect where it was missing but I'm sure VS has a way as well..)
Cheers.
Related
(I've looked far and wide but I can't even find anyone having the same problem, not to mention a fix or anything. Closest is this thread which just announces the feature...)
The way it currently works for me, the VS2019 code lens integration of P4VS (for C++ at least) is almost completely pointless. Each function has an indicator added, but the information in each is identical - namely the change history of the entire file:
According to this Microsoft article, I would expect to either get function-level change information that pertains only to that function or a single change summary of the file at the bottom of the editor. But instead I get the worst combination of both.
I'm mainly surprised that I can't find anyone else talking about this, so I assume something is misconfigured on my part. Can't find anything in the configuration options though...
Is this just a bad implementation by Perforce or is something wrong on my end?
I have just found out that it can be turned off by Visual Studio options.
How to turn off CodeLens-References
Text Editor > All Languagues > CodeLens
Okay so I just made a C++ program that is basically a notebook,
you write stuff in it and it saves it to a .dat file and then you can
read it later.
I compiled it with Microsoft Visual C++ and now I sent it to a friend and it's
saying that it is a virus? I scan it online and it also says that it's a virus.
I don't know why this is happening, as I literally just used some if/else statements, created some strings and used a couple getlines. (and fstream to create the .dat files).
This is the virus report: https://www.virustotal.com/en/file/a1b72280a32915429607fd5abeef1aad4f8310867df1feb7707ea0f7a404026e/analysis/1455735299/
Here is my code. (Its 400+ lines). And I'm almost certain there's nothing wrong
with it. http://pastebin.com/ZwJZrRSu
Any idea why this is happening?
Most probably your PC is already infected by a virus, which adds itself to any executable it can find on your machine. That would easily explain this behavior. Try to compile the same program on PC that is clean for sure and check your PC by antivirus.
I am not sure but I think it because you imported kernel32.dll
Again, it is hard to tell without the source
Also take a look at the file detail in the report
I wrote a lot of code in C++ and save. After that I want only try some example code which I find. So I paste this code in this my project main.cpp file (where I had my code). I try it example code and mistake close this file. After that I open main.cpp file, but I can't undo changes by Ctrl-Z. I wanted only try example code and then I wanted undo changes by Ctrl Z, but my mistake is close file. Is it possible undo changes after close file or restore it?
Your original code is probably gone for good. However, perhaps this is a good time for you to consider adding a version control system to your tool set, which will help you avoid this kind of mistake in future, as well as give you a lot of other benefits.
Also, it is not a wise idea to paste example code over your own work in the way that you've done, for exactly the reason you've discovered. Insert a new file into your project, or create a separate project for testing example code. I have a separate Visual Studio solution specifically for this purpose.
EDIT: I say "probably" because I can't rule out all possibility of recovery based on the information you've supplied (e.g. you might have some kind of scheduled backup which caught your previous version). Also, if the code you pasted over it was shorter than your original code, it's possible that some of it still exists as unused data blocks on your hard drive, and might be recoverable, assuming something else hasn't already overwritten them.
This is the first time I am writing in this forum, I hope someone could help me. I have been searching on the Web but have not found any answer related to my question.
I have a very large file (about 25000 lines) with thousands of definitions that must be used by another file
All these files (and about 600 more of them) are converted to .c files using a special tool. I am almost sure this conversion is made propertly.
If I create a.exe with all these files, there is no problem and everything works all right. Unfortunately, I need a .dll which crashes when I try to access to the very large file.
I have check that its .obj file is larger than 65MB so I have added the compiler command /bigobj as far as I have seen on the Internet but it didn't solve the problem.
I have also checked that the problem happens when access to the large file because everything works ok when I join both files (which is not possible in my development)
I am using Visual 2008
Could it be related to compile as C (/TC) or C++ (/TP) code? What's the difference between .exe and .dll that may make my program crashes?
Any ideas please?
Thanks in advance
Indeed, without the code not much can be said... (tho not sure if anyone would have the patience of reading 600 files each with 25k lines of code :) )
As advice, rebuild the exe and dll in debug mode, run the exe from MSVC, then put a breakpoint where you know it crashes. Next set a data breakpoint on the variable after you get its address from the watch window. ASSUMING the app does what it should correctly, then the pointer is set, but lost along the way; that means it should be triggered twice.
Alternatively, try an assertion check.
Another scenario is because the variable is volatile.
Another scenario is the value is returned from a temporary value and gets lost...
And last but not least, the value is never set because of wrong\bad conditions...
If your problem is the crash and not the missing value, just do a null check and return the call if you really want to avoid the complication, however, I would recommend you find why the value isn't set. Your choice.
I have a source file in my project, which has more than 65,536 code lines (112,444 to be exact). I'm using an "sqlite amalgamation", which comes in a single huge source file.
I'm using MSVC 2005. The problems arrives during debugging. Everything compiles and links ok. But then when I'm trying to step into a function with the debugger - it shows an incorrect code line.
What's interesting is that the difference between the correct line number and the one the debugger shows is exactly 65536. This makes me suspect (almost be sure in) some unsigned short overflow.
I also suspect that it's not a bug in the MSVC itself. Perhaps it's the limitation of the debug information format. That is, the debug information format used by MSVC stores the line numbers as 2-byte shorts.
Is there anything can be done about this (apart from cutting the huge file into several smaller ones) ?
According to a MS moderator, this is a known issue with the debugger only (the compiler seems to handle it fine as you pointed out). There is apparently no workaround, other than using shorter source files. See official response to very similar question here
Well, when I wanted to look at how sqlite works, I took the last 60000 or so lines, moved them to another file and then #include'd it. That was easy and did the trick for me. Also, if you do that, be careful not to split inside #ifdef .
If you look at the documentation for the symbolic debugging info, you will see the type used for line numbers. For example, both line and column parameters for IDiaSession::findLinesByLinenum are of type DWORD.
Edit: As #valdo points out, that still doesn't mean the debugger works properly with huge line numbers. So you have to use shorter files. It is unfortunate that such limitation exists, but even if there wasn't I'd still recommend you split your source.
Have you looked into using WinDBG instead? It's pretty capable as the Windows team use it for debugging the O/S and there's some biiiig files in there, or at least there was when I last looked.
For anyone having issues with incorrect line numbers for files < 65536 lines: I found my issue was because of inconsistent line endings in the source file. There were 129 \r newlines where the rest of the file was \r\n style. The difference between the debugger line and the correct line was 129 as well.
Unless you are modifying SQLite, you should just trust that it is doing its job. No need to step in at all. SQLite is run through a large battery of tests before release.