Someone has reported a bug in my program, which brings up the following error message:
The error occours in a C++ DLL of the program, which was compiled by VS2008. I can reproduce the error, but am not able to find out what´s the problem. I´ve already done a bunch of tests for memory leaks or wrong alloctions, but with no success.
Now the weird thing: when I add a main function to the code, compile it as an EXE and then run the exactly same thing, all is ok. The error occours only as a DLL.
The next strange thing is, that when I press "Ignore", the program continues and does its job as expected.
So, I´m looking for 2 types of answers:
- Answers that help me find the bug
- Answers that help me to "auto-ignore" or hide this errormessage, so that it does not occour. That would be ok, since there is no difference in the result.
I´m thankful for any help or advise.
Thanks!
Update
Like Joachim Pileborg said, I´ve created a simple test c++ project, that calls my DLL, and it works perfectly! The program that normally calls the DLL is written in DELPHI, so I think it could be a bug of DELPHI... Weird: The call of the DLL works for 99.9999..%, but in one specific case, there occours an error IN the Dll. It´s not the call that fails... Really, really strange story :S
Ok... that is a negative number. The simpler thing... perhaps your code is doing a malloc with an invalid\negative size?
The strange thing is that that number in binary is 11111111111111111111111111111100, probably your size calculation is wrong. It can be however a more complicated error, for example due a buffer overflow.
You should not ignore this error at all, can be a symptom of a more complicated and dangerous error.
Try to debug your allocation, try to get exactly the piece of code that is doing this invalid allocation.
You can overload the new operator or redefine the malloc replacing them your debug functions where you can check the passed arguments (size).
4294967292 - that is (unsigned)-4. You are either doing some computation of the size to be allocated wrong, some integer has overflown or somesuch.
I'd try to put a breakpoint on malloc (or whatever allocation function that is) and check where does the bad value come from.
Through the debugger, I was able to see the call stack, and what function in the code displayed the error. After searching for this routine, I could find out how to disable displaying it.
Related
I'm making game engine in c++ which is compiled into dll. For last 2 weeks i was doing very boring cleaning of code to make it easier to use, unfortunantely didnt make any backup. Now when i put call to any function from that dll inside executable code it shows error window, when executable starts, which tells error code 0xc0000142. Compiler doesnt show any warning that could lead to this, no linking error, nothing. I have no clue what could do this. I'm using linker to link dll instead of loading it dynamically. Does anybody know what can trigger this error?
if not delay-load, when you load the process, the dll will also be brought to memory. so this error happens.
How to tackle?
I suggest you to make a fresh plain executable with just basic code and insert this dll. try it.
if successful, insert a function call on a non-functional code (should not be called on startup) and try it.
if the above succeeds, try to add the function call on functional code and try it.
if works means simple DLL is clean.
Then what happens to your original exe, there is a good chance that the a bad copy of DLL is placed in PATH. it is causing the error.
if anything fails in between, you can figure out the issue from DLL. in that case, I suggest you to comment out all code with a fresh blank function. DllMain way next.
sorry for the 'open ended' answer. but for debugging I think you need some pointers to think. you are the one ultimately going to find the result. please post the findings.
Good. Usage of exception is good in scenarios like construction. It does not add much performance overhead when things go well. But neat when nasty things happen. especially good when you give the code to others to maintain.
Background
I've got about a terabyte of files with raw data, with a relatively small subset of labelled data. I've written c++ code (calling some ancient MSVC++2003 code I heavily modified to get it to compile on recent compilers) to aggregate the annotated data slices.
A big part of that labelled data is concentrated in one file, but that file turns out to be the one where my program crashes.
Problem
I'm getting
Invalid parameter passed to C runtime function.
Invalid parameter passed to C runtime function.
terminate called after throwing an instance of 'int'
In my Qt output window, and windows tells me the same in a popup, but at this point it's too late to get any useful info out of the executable / debugger it seems (though I'm not experienced at all with Qt's debugger).
What I have tried
I've googled all over and found plenty of people with this error message but it's so generic that none of their issues could be the same as mine, and there's such a long list of different C runtime functions that sifting through all of them is slow and it doesn't seem to help.
My question
"Find a man a bug, and you help him for a day. Teach a man to debug and you help him for a lifetime. Post the way on stackoverflow and you help many men and get a lot of upvotes."
Is there a generic method to find what C runtime function the problem was and what the argument was? Did I miss some fancy debugger features? Is there anything else you could recommend or info I could provide?
I'd hope to get a catch-all answer to this to help everyone with this problem, not just me, but I'll be glad if I'm helped too of course.
Specific to my problem:
My stack trace is as follows:
0 ntdll!DbgBreakPoint 0x7727000d
1 ntdll!DbgUiRemoteBreakin 0x772ff156
2 ?? 0x6f06eaa1
3 KERNEL32!BaseThreadInitThunk 0x7501338a
4 ntdll!RtlInitializeExceptionChain 0x77299902
5 ntdll!RtlInitializeExceptionChain 0x772998d5
6 ??
and gdb can't get a better trace it seems (anything I try to do with it gets me a timeout error).
After trying a couple more functions just to be sure everything gave a timeout trying "backtrace" once again did give me a result. I guess I just never put this much time in gdb after it timeouting on me once.
That said, I might be able to find something with this new info. Consider my specific problem closed, but my general point is still valid I believe: I've now found the function with the problem (I think), but not why it is a problem, nor what the invalid parameter is. Even better, I've traced it to a line where it says "throw 1". So now I'm assuming windows/Qt translates that to the "invalid parameter". But it's not true.
It can just be some bad code, it does not even need to be a C function, and nothing needs to be wrong with your parameters.
...
#17 0x00c17d72 in libstdc++-6!.cxa_throw () from C:\Qt\5.5\mingw492_32\bin\libstdc++-6.dll
No symbol table info available.
...
Since the log is printed to the debug console then it should be reported by OutputDebugStringA function. You can place a breakpoint on the function to see who results in that log. To place a breakpoint on a function you can Ctrl+B in Visual Studio and enter function name:
But this might not work, or you may have too many other messages logged using OutputDebugStringA. Usually Invalid parameter passed to C runtime function is reported by _invalid_parameter, so, you may as well try to place a breakpoint on _invalid_parameter function. This might not work as well because it could be reported from some other system dll that your process links to: ntdll.dll, KernelBase.dll etc. To place a breakpoint on a function exported by a dll you need to use: <dll>!<exportname>:
_invalid_parameter
ntdll.dll!__invalid_parameter
KernelBase.dll!__invalid_parameter
msvcrt.dll!__invalid_parameter
ucrtbase.dll!__invalid_parameter
All of these are different functions and you can see their addresses:
In my case only when I set a breakpoint on ntdll.dll!__invalid_parameter I was able to see backtrace and the log message was caused by GetAdaptersAddresses winapi. The reason breakpoint on OutputDebugStringA wasn't helpful was because the log was printed through DbgPrint api. Placing breakpoint on DbgPrint works in this case.
In Visual Studio 2017 at least, you can hit CTRL+B and add a function breakpoint on _invalid_parameter. This will stop your program at the point where the message would have been logged, which will let you find the offending function in the call stack. It will work even if someone else's code undoes your call to _CrtSetReportMode().
Things I learned from this question (and that might help people searching for this question) :
Turns out that this error could be traced back to a line of code saying
throw 1;
This means It can just be some bad code, it does not even need to be a C function, and nothing needs to be wrong with your parameters. Searching your code and libraries' source for "throw"
Turns out that getting timeouts on gdb are not an indicator of anything. Keep trying things and retrying and maybe at one time you might get a stack trace.
Personally, on a Linux terminal, I use gcc for compiling and gdb for debugging. To compile a program with debugging options using gcc, you simply have to add a -g to your other flags. Ex:gcc file.c -o file -std=c99 -g. You can then type gdb file and you enter into an interactive debugger. Among other helpful things, you can run the program, call functions and insert breakpoints. For a full and well explained usage go to this website-http://www.tutorialspoint.com/gnu_debugger/index.htm
I ran into this same error message "Invalid parameter..." while debugging a windows driver.
The technique on this page, even though for Windows and not exactly addressing for this question, might be useful to someone who is looking for this particular error message. IOW HTH..
http://dennisyurichev.blogspot.com/2013/05/warning-invalid-parameter-passed-to-c.html
So in summary you have to narrow down specific to your environment where a debug string is being output by possibly a debugging "helper" library function. Once known, set a breakpoint there and then look back up the call stack. IMHO, it's a very clever solution to what can be a tough location to find.
If you are using MinGW only (no Visual Studio build stuff). Try compiling your application for the Console subsystem instead of the Windows subsystem when building debug version. In that case when an invalid argument is passed to a C function the function will fail and will trip your error handling code instead of the standard library's error box which should give you better control over what is happening.
I often wrap c++ classes using cython. All the calculations are done in c++ and cython is only used to pass variables to the constructor and get the results from c++.
For a recent project, I am having the following problem: The code (which initializes a class and then calls a method) always runs fine initially, but after calling the same method repeatedly (I can't reproduce when exactly), it suddenly runs a factor of at least 1000 slower than normal when calling the same method.
My question is: What could cause such a seemingly random behavior and how would you go about debugging it?
I know this is impossible to solve without seeing the code, but it's large and I don't know where the problematic behavior comes from. I'm just asking for hints and strategies of how to solve it.
Things I've tried:
Checked the c++ code for leaks.
tried different compiler directives (#cython: wraparound=False, boundscheck=False, ...)
A hint could be that if I run the python code without the --pylab option of ipython it complains about a symbol not being found, but that's the only problem I have been able to identify.
It was an uninitialized member that occasionally caused a problem, not a memory leak. Thanks to those who tried to help!
The issue with ipython remains, but I posted that in another question.
I am learning TDD and using CppUTest in eclipse.
Is there any way to debug my code getting a nagging segmentation fault.
Thanks
I don't know anything special in CppUTest or Eclipse to help you, but some generic segfault debugging ideas seem appropriate here:
Add flushing print statements (e.g. printf(...) + fflush(stdout) or fprintf(stderr, ...)) to your code and see what gets printed. Do this in a binary search fashion with just a few prints at a time until you narrow down exactly where it is crashing. This sounds old fashioned but is extremely effective. Here is a guide I found googling that talks about this well-known technique: http://www.floccinaucinihilipilification.net/blog/2011/3/24/debugging-via-binary-search.html
Compile your code with debugging symbols and run it in a debugger. When you hit your segfault, ask for a backtrace and see if you can figure out what happened. When doing this it can be especially helpful to use a graphical debugger.
Run your code with a debugging tool like a debug malloc library or something from the valgrind suite. This may catch problems that are root causes of your segfaults but aren't occuring at the exact place where the segfault is generated (e.g. double frees, out of bound array access clobbering pointers used later, etc).
It would be helpful if you could add some code to your question, to give us a better idea of what you are up against. Not knowing any of the details, I would suggest the following:
Add -vto your executable's arguments in the Debug dialog. This will print the names of your test cases as they are executed. The last name that prints is likely the test where the segmentation fault occurs.
Put a breakpoint in that test case, where you call your code under test
Step into your code until the segfault occurs.
Trace back the value that caused the segfault (most often, a dangling pointer) and find out, why it was NULL or uninitialized.
This is utterly mystifying me. I have, in my class declaration, two lines:
std::multimap<int, int> commands;
std::multimap<std::string, std::string> config;
The code compiles without issue, but when I run it, I get the following error:
*** glibc detected *** ./antares: free(): invalid pointer: 0xb5ac1b64 ***
Seems simple enough, except that it has nothing to do with how the two variables are later handled. I removed all references in the rest of the code to the variables - still crashed. I commented out one of the lines - either one, and the program ran without issue. How can the error not be with either particular variable? I'm working under the assumption that there isn't a bug in STL, but I've run out of ideas on how my code could possibly be doing this.
This one has me stumped, so I'd appreciate any help you can provide.
Wyatt
EDIT: I'm not suggesting there's a problem with STL, that was just me being a bit glib. I know the bug is in my code, what I want to know is - what could possibly be wrong that declaring an unreferenced variable would cause it to crash? Why would that affect my code at all?
My code is a few thousand lines long, so it's not really worth anyone's time reading through it, I'm just looking for someone to point me in the right direction.
You're correct to assume the problem isn't in GCC or the STL. However, if the maps are causing free errors, your other code is likely stack smashing (or heap smashing). A truly terrible bug to chase down. The worse part about stack smashing is the object that breaks is not the object with the bug.
Here are some debugging tips.
Run the app under valgrind.
define _GLIBCXX_DEBUG to enable stl debugging
add MALLOC_CHECK_=1 as an environment variable. This will give you better malloc error messages. More info here.
On rare occasions I have been able to add a memory watch to the location that will be smashed. But it is rare when you can predict where the smashing will occur.
You are right: the crash is not from these two lines - they just make it visible.
Here's how to diagnose this problem:
first, leave your variables defined (make your program crash)
second, remove or disable other parts of your code until the crash stops happening. Then you will know an approximate area that corrupts your memory.
third (once you have an area that when disabled stops the crash) start enabling parts of it until the crash happens again.
Edit: I'd say your problem is with code that contains your two multimaps (a copy constructor or assignment operator is missing or something like that). It's just a wild guess so don't put much stock on it.