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.
Related
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.
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.
One of my co-workers shipped a hot fix build to a customer, and subsequently deleted the pdb file. The build in question is crashing (intermittently) and we have a couple of crash dumps. We have all the source code in version control, and can compile it to an equivalent .exe and get symbols for that one. However, those symbols don't match the crash dump exactly. It seems like several of the functions are off by some constant offset, but we've only looked at a handful.
I'd love to be able to do the following (I can fake parts of this manually, but it's a huge amount of work): get a stack trace for each thread in the dump and cast pointers in the dump to the appropriate type and have them show up in the Visual Studio debugger. I'm using 2005, if that matters.
Is there a tool to let us recreate a pdb given the source code, all the .obj files, and the original .exe? Or is there a setting when we compile/link to say "make it exactly like this other exe you just did" or something like that?
Quick update, based on answers so far: I have the exe file that we sent to the customer, just not the pdb that corresponds to it, if that helps. I'd just as soon not send them a new build (if possible), because it takes about a week of running to get the crash dumps, and the customer is already at the "why isn't this already fixed?" stage. (If we do send another build, I'd prefer it to be one that either fixes the problem or has additional debugging in the area of interest, not just the same code.) I know it's possible to do some of this manually with a lot of guesswork; that's what we're currently doing. But it's a pain, so I'm hoping there's a way to automate it.
You cannot recreate a PDB to match a pre-existing executable. The PDB contains a "finger print" that is unique for each compilation. Unless you can make the old PDB magically reappear, you should whack your cow-orker in the back of the head (Gibbs-style, if you watch NCIS), recompile the whole thing, store the PDB somewhere safe, and ship a new executable to your customer, and let the crashes come.
If your build system enables you to recreate any binary from any revision you have in your history, then you should be able to get the build ID from the customer, and regenerate that same exact build ID, along with all the binaries and so forth. That will take a while if you have a large project, of course, but it will also yield the debugging file that you need.
If you have no way to perform an exact reproduction of a build, then look at this situation, think hard about some others that might crop up, and start moving to make it possible to regenerate all successful builds and associated files in the project's history. This will make it much easier to be able to work problems like this in the future.
When you have the sources, it's quite easy to find the correspondence between them and the exe file. Just ask them to send you the exe file along with the crash log and use IDA.
What you are asking is much more difficult than that, considering also that you need it for "one use only".
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.