My program crashes before main() function. I determine this using "cerr":
int main(int argc, char **argv)
{
cerr << " MAAIN " << endl;
The message from gdb:
Reading symbols for shared libraries ...........+++............................ done
CA(34652) malloc: *** error for object 0x7fff76694860: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT, Aborted.
0x00007fff88e1782a in __kill ()
(gdb) bt
#0 0x00007fff88e1782a in __kill ()
#1 0x00007fff8c4d2a9c in abort ()
#2 0x00007fff8c53184c in free ()
#3 0x00000001026a1db0 in std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::overflow ()
(gdb)
I have checked the code for "delete" and "free" functions. All deletes are done with check like this:
if (x) delete x;
Please help me with answering two questions:
1. What can be the possible problem?
2. How to find it? (I have a big code with a lot of files and cmake for compilation).
P.S. I read Is there any way a C/C++ program can crash before main()? but looking at gdb massage I suppose libraries are ok.
cout is not a good way to check where your program is crashing because cout does not immediately flush its buffer and it is possible that you programs crashes after cout but before flushing buffer. it's better to check it with cerr instead of cout
And before main function, constructors of global variables will call. so take look at them if you think it crashes before start.
an other possibility is allocating memory for arrays in you main function that happens before calling of main function. if they are huge. you must use new to allocate memory for them.
std::basic_stringbuf<char, std::char_traits<char>... tells me that it's std::string that is going wrong. One quite possible scenario is that you have something that is trying to "free" a string, that hasn't been constructed correctly or that has been overwritten by uncareful use of arrays.
Or you are relying on some global variables in different source files, so you have something like this:
// main.cpp:
...
extern string str; // str lives in another .cpp file
....
myclass x(str); // Construction using str.
// otherfile.cpp
string str("foobar");
In this case, str may not be constructed by the time x is being constructed, and the string is "invalid".
There are oodles of other possibilities along similar lines.
The address here: 0x7fff76694860 is on the stack. If it's always the same value, you could try to track down where it is.
Related
I am creating a library that contains functions that can throw exceptions. To debug programs that use my library, I would like to provide a custom format-method that will give the programmer more information about these exceptions if they are uncaught by main().
Generally, my library can be called from a main function() written by an end user. The end user does not put a try..catch block in main() because the end user does not expect these exceptions (they should actually be avoided and/or caught by other, buggy libraries, between my library and main(), but they're not, and that's what we need to debug).
// The following example would actually be multiple files,
// but to keep this example simple, put it in "<filename>"
// and compile the following with "g++ <filename>".
// library file
class My_Exception
{
public:
char const* msg;
My_Exception(char const* msg) : msg(msg) {}
};
void Library_Function(bool rarely_true = false)
{
if (rarely_true)
throw My_Exception("some exceptional thing");
}
// note to discerning user: if you use the "rarely_true" feature,
// be sure to remember to catch "My_Exception"!!!!
// intermediate, buggy, library (written by someone else)
void Meta_Function()
{
Library_Function(true); // hahahaha not my problem!
}
// main program (written by yet someone else, no "try..except"
// allowed here)
int main()
{
Meta_Function();
}
When I run the above program, I get:
terminate called after throwing an instance of 'My_Exception'
Abort (core dumped)
I like the way there is an error message telling me about the uncaught exception. I would like to know the best way to add a hook to My_Exception so that the msg string would also be printed in this situation.
I am willing to register callbacks with the runtime system, or add methods to My_Exception, but I don't want to mess with main() itself. (I know this problem could be solved by telling the linker to use a different entry point having a try..catch, and wrapping main() in that, but it will be hard to get the end-user to adopt something like that).
Clearly there is already some exception-checking code after main(), as the above message was printed. The stack trace is:
#0 0x0000155554c0d428 in __GI_raise (sig=sig#entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x0000155554c0f02a in __GI_abort () at abort.c:89
#2 0x000015555502e8f7 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x0000155555034a46 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x0000155555034a81 in std::terminate() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x0000155555034cb4 in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00000000004006eb in Library_Function() ()
#7 0x00000000004006f4 in main ()
(gdb)
Aside: I don't at all understand why gdb says the program is aborting in Library_Function. That sounds wrong; it should at least have exited from main() after main() failed to catch the exception. Must be some language detail, like it preserves the stack until the exception is handled? In any case, I digress.
Maybe we can extend std::terminate() or cxa__throw() or some other runtime component to print msg in this case?
How this question is different
How come I don't can't print out error from my throw exception? 2 answers -- similar, but 1. my question involves an exception object (not a string) and therefore the point about custom formatting (in the question title) is relevant. 2. missing keyword "uncaught" from the title, so hard to find
Custom error message of re-thrown exception not printed by what() 1 answer
-- 1. already contains an answer to my question in their question, so cannot be the same question. Unless you consider "what tool pounds a nail" to be the same question as "why isn't my hammer working". 2. missing keyword "uncaught" from the title
looser throw specifier for ‘virtual const char ro_err::StdErr::what() const’ 1 answer*
-- 1. already contains an answer to my question in their question, so cannot be the same question. Unless you consider "what tool pounds a nail" to be the same question as "why isn't my hammer working". 2. missing keyword "uncaught" from the title
As suggested by πάντα ῥεῖ, you can try this
class myexception : public exception
{
public:
const char* what() const noexcept override
{
char* ch = "some exceptional thing";
return ch;
}
};
void Library_Function(bool rarely_true = false)
{
if (rarely_true)
throw myexception();
}
int main()
{
try
{
Library_Function(true);
}
catch (myexception& err)
{
std::cout << err.what();
}
return 0;
}
I am on Linux (CentOS 7.4, compiler Clang) and getting a segmentation fault (not easily reproducible) within a C++ struct object. This is a class member of a polymorphic object I do not allocate, but is instantiated within a framework I do not have the source code to. This means I cannot compile using sanitize easily and Valgrind increases the initialisation time from seconds to 5 minutes):
// C is allocated within a third party framework, I assume they use new()
//
class C : public ThirdPartyParentClass
{
S s;
}
struct S
{
.
std::mutex _mutex;
.
};
the segmentation fault corrupts _mutex.
I therefore added a char buffer so I could see the corruption:
struct S
{
.
char _buffer[1000];
std::mutex _mutex;
.
};
and I can see the corrupted bytes when the segmentation fault occurs. However, I cannot determine when the corruption takes places.
To determine when the corruption takes place I would like to protect the char buffer bytes. I tried:
struct S
{
S()
{
mprotect(&_buffer[0], 4096, PROT_NONE);
const int test = buffer[0]; // Trigger seg fault to test it works
}
.
char _buffer[4096]__attribute__((aligned(4096)));
std::mutex _mutex;
.
};
but my test to determine the memory protection is working, doesn't cause a seg fault.
Could somebody please help?
Doing this at the source level is a bit silly. If you want to find the exact moment when something gets written to a particular memory address, use a data breakpoint (gcc calls them "watchpoints"). Just do watch *(int*)0xWHATEVER on the area of memory you expect to be corrupted, and it'll break on the first modification, with very low overhead.
I'm making a simple deck/card/hand object oriented system for a university assignment, and I've become stuck on this problem.
I've set up a simple test class which calls various methods in objects.
int main() {
Deck deck = Deck();
deck.DisplayDeck();
deck.Shuffle();
deck.DisplayDeck();
Hand hand = Hand(1);
Card* card;
card = deck.DealNextCard();
hand.AddCard(card);
hand.ftring();
deck.DisplayDeck();
}
The problem comes at hand.ftring(). When I call this, it causes a segmentation fault. The weird thing is, it contains no code.
in hand.cpp:
string Hand::ftring() {
}
If I remove it, it runs to completion. If I add a console output to the method, it prints it and then crashes. I'm completely at a loss as to what to do, as the debugger only states
Program received signal SIGSEGV, Segmentation fault.
In ?? () ()
You declare that you are returning a string in ftring function, but you don't actually return anything. This is bad.
Your method must return a string - this is the way you've declared it. You're getting undefined behavior.
(Note to any future readers: The error, unsurprisingly, is in my code and not std::_Rb_tree_rebalance_for_erase () )
I'm somewhat new to programming and am unsure how to deal with a segmentation fault that appears to be coming from a std function. I hope I'm doing something stupid (i.e., misusing a container), because I have no idea how to fix it.
The precise error is
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000000c
0x00007fff8062b144 in std::_Rb_tree_rebalance_for_erase ()
(gdb) backtrace
#0 0x00007fff8062b144 in std::_Rb_tree_rebalance_for_erase ()
#1 0x000000010000e593 in Simulation::runEpidSim (this=0x7fff5fbfcb20) at stl_tree.h:1263
#2 0x0000000100016078 in main () at main.cpp:43
The function that exits successfully just before the segmentation fault updates the contents of two containers. One is a boost::unordered_multimap called carriage; it contains one or more struct Infection objects. The other container is of type std::multiset< Event, std::less< Event > > EventPQ called ce.
void Host::recover( int s, double recoverTime, EventPQ & ce ) {
// Clearing all serotypes in carriage
// and their associated recovery events in ce
// and then updating susceptibility to each serotype
double oldRecTime;
int z;
for ( InfectionMap::iterator itr = carriage.begin(); itr != carriage.end(); itr++ ) {
z = itr->first;
oldRecTime = (itr->second).recT;
EventPQ::iterator epqItr = ce.find( Event(oldRecTime) );
assert( epqItr != ce.end() );
ce.erase( epqItr );
immune[ z ]++;
}
carriage.clear();
calcSusc(); // a function that edits an array
cout << "Done with sync_recovery event." << endl;
}
The last cout << line appears immediately before the seg fault.
My idea so far is that the rebalancing is being attempted on ce immediately after this function, but I am unsure why the rebalancing would be failing.
Update
I've confirmed the seg fault goes away (though the program then immediately crashes for other reasons) when I remove ce.erase( epqItr );. I am able to remove events successfully in another place in the code; the code I use there to erase items in ce is identical to what's here.
Backtracing without optimization (thanks, bdk) reveals much more information:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000000c
0x00007fff8062b144 in std::_Rb_tree_rebalance_for_erase ()
(gdb) backtrace
#0 0x00007fff8062b144 in std::_Rb_tree_rebalance_for_erase ()
#1 0x00000001000053d2 in std::_Rb_tree, std::less, > std::allocator >::erase (this=0x7fff5fbfdfe8, __position={_M_node = 0x10107cb50}) at > stl_tree.h:1263
#2 0x0000000100005417 in std::multiset, std::allocator >::erase (this=0x7fff5fbfdfe8, __position={_M_node = 0x10107cb50}) at stl_multiset.h:346
#3 0x000000010000ba71 in Simulation::runEpidSim (this=0x7fff5fbfcb40) at Simulation.cpp:426
#4 0x000000010001fb31 in main () at main.cpp:43
Unless Xcode is reading line numbers wrong, the only stl_tree.h in my hard drive is blank on line 1263.
A few people asked to see the function that calls recover. It's a bit complicated:
struct updateRecovery{
updateRecovery( int s, double t, EventPQ & ce ) : s_(s), t_(t), ce_(ce) {}
void operator() (boost::shared_ptr<Host> ptr ) {
ptr->recover( s_, t_, ce_ );
}
private:
int s_;
double t_;
EventPQ & ce_;
};
// allHosts is a boost::multiindex container of boost::shared_ptr< Host >
// currentEvents is the EventPQ container
// it is an iterator to a specific member of allHosts
allHosts.modify( it, updateRecovery( s, t, currentEvents ) );
cout << "done with recovery" << endl;
The last cout prints. The code worked before without this particular version of the recovery function.
Noah Roberts correctly pointed out that the problem is at Simulation.cpp, line 426. Jump below for embarrassing solution.
Possibly you're holding onto an iterator into ce across the call to recover. If recover happens to remove that item the iterator will be invalidated and any future use (say an attempt to erase it) could result in a seg fault.
It would help if we could see more context of how ce is used before and after the call to recover.
The problem was that on line 426 of Simulation.cpp, I tried to delete an event in the EventPQ currentEvents (a.k.a. ce) container that my recover() function had just deleted. The iterator had obviously been invalidated. Dumb.
Lessons:
Debug on code that has not been optimized
Pay close attention to what the non-std related frames imply
And for the future: Trace memory in valgrind
I'm still stumped why the debugger referred me to an apparently blank line in stl_tree.h.
I've massive appreciation here for the people who have helped me work through this. I'm going to revise my question so it's more concise for any future readers.
Perhaps the call to assert is not compiled with your configuration. Assertions in production code are usually a Bad Idea[TM].
You could also be exceeding immune's boundaries.
Try:
if (epqItr != ce.end())
{
ce.erase(epqItr);
if (z is within immune's bounds)
{
++immune[z];
}
}
I'm writing a memory tracking system and the only problem I've actually run into is that when the application exits, any static/global classes that didn't allocate in their constructor, but are deallocating in their deconstructor are deallocating after my memory tracking stuff has reported the allocated data as a leak.
As far as I can tell, the only way for me to properly solve this would be to either force the placement of the memory tracker's _atexit callback at the head of the stack (so that it is called last) or have it execute after the entire _atexit stack has been unwound. Is it actually possible to implement either of these solutions, or is there another solution that I have overlooked.
Edit:
I'm working on/developing for Windows XP and compiling with VS2005.
I've finally figured out how to do this under Windows/Visual Studio. Looking through the crt startup function again (specifically where it calls the initializers for globals), I noticed that it was simply running "function pointers" that were contained between certain segments. So with just a little bit of knowledge on how the linker works, I came up with this:
#include <iostream>
using std::cout;
using std::endl;
// Typedef for the function pointer
typedef void (*_PVFV)(void);
// Our various functions/classes that are going to log the application startup/exit
struct TestClass
{
int m_instanceID;
TestClass(int instanceID) : m_instanceID(instanceID) { cout << " Creating TestClass: " << m_instanceID << endl; }
~TestClass() {cout << " Destroying TestClass: " << m_instanceID << endl; }
};
static int InitInt(const char *ptr) { cout << " Initializing Variable: " << ptr << endl; return 42; }
static void LastOnExitFunc() { puts("Called " __FUNCTION__ "();"); }
static void CInit() { puts("Called " __FUNCTION__ "();"); atexit(&LastOnExitFunc); }
static void CppInit() { puts("Called " __FUNCTION__ "();"); }
// our variables to be intialized
extern "C" { static int testCVar1 = InitInt("testCVar1"); }
static TestClass testClassInstance1(1);
static int testCppVar1 = InitInt("testCppVar1");
// Define where our segment names
#define SEGMENT_C_INIT ".CRT$XIM"
#define SEGMENT_CPP_INIT ".CRT$XCM"
// Build our various function tables and insert them into the correct segments.
#pragma data_seg(SEGMENT_C_INIT)
#pragma data_seg(SEGMENT_CPP_INIT)
#pragma data_seg() // Switch back to the default segment
// Call create our call function pointer arrays and place them in the segments created above
#define SEG_ALLOCATE(SEGMENT) __declspec(allocate(SEGMENT))
SEG_ALLOCATE(SEGMENT_C_INIT) _PVFV c_init_funcs[] = { &CInit };
SEG_ALLOCATE(SEGMENT_CPP_INIT) _PVFV cpp_init_funcs[] = { &CppInit };
// Some more variables just to show that declaration order isn't affecting anything
extern "C" { static int testCVar2 = InitInt("testCVar2"); }
static TestClass testClassInstance2(2);
static int testCppVar2 = InitInt("testCppVar2");
// Main function which prints itself just so we can see where the app actually enters
void main()
{
cout << " Entered Main()!" << endl;
}
which outputs:
Called CInit();
Called CppInit();
Initializing Variable: testCVar1
Creating TestClass: 1
Initializing Variable: testCppVar1
Initializing Variable: testCVar2
Creating TestClass: 2
Initializing Variable: testCppVar2
Entered Main()!
Destroying TestClass: 2
Destroying TestClass: 1
Called LastOnExitFunc();
This works due to the way MS have written their runtime library. Basically, they've setup the following variables in the data segments:
(although this info is copyright I believe this is fair use as it doesn't devalue the original and IS only here for reference)
extern _CRTALLOC(".CRT$XIA") _PIFV __xi_a[];
extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[]; /* C initializers */
extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[]; /* C++ initializers */
extern _CRTALLOC(".CRT$XPA") _PVFV __xp_a[];
extern _CRTALLOC(".CRT$XPZ") _PVFV __xp_z[]; /* C pre-terminators */
extern _CRTALLOC(".CRT$XTA") _PVFV __xt_a[];
extern _CRTALLOC(".CRT$XTZ") _PVFV __xt_z[]; /* C terminators */
On initialization, the program simply iterates from '__xN_a' to '__xN_z' (where N is {i,c,p,t}) and calls any non null pointers it finds. If we just insert our own segment in between the segments '.CRT$XnA' and '.CRT$XnZ' (where, once again n is {I,C,P,T}), it will be called along with everything else that normally gets called.
The linker simply joins up the segments in alphabetical order. This makes it extremely simple to select when our functions should be called. If you have a look in defsects.inc (found under $(VS_DIR)\VC\crt\src\) you can see that MS have placed all the "user" initialization functions (that is, the ones that initialize globals in your code) in segments ending with 'U'. This means that we just need to place our initializers in a segment earlier than 'U' and they will be called before any other initializers.
You must be really careful not to use any functionality that isn't initialized until after your selected placement of the function pointers (frankly, I'd recommend you just use .CRT$XCT that way its only your code that hasn't been initialized. I'm not sure what will happen if you've linked with standard 'C' code, you may have to place it in the .CRT$XIT block in that case).
One thing I did discover was that the "pre-terminators" and "terminators" aren't actually stored in the executable if you link against the DLL versions of the runtime library. Due to this, you can't really use them as a general solution. Instead, the way I made it run my specific function as the last "user" function was to simply call atexit() within the 'C initializers', this way, no other function could have been added to the stack (which will be called in the reverse order to which functions are added and is how global/static deconstructors are all called).
Just one final (obvious) note, this is written with Microsoft's runtime library in mind. It may work similar on other platforms/compilers (hopefully you'll be able to get away with just changing the segment names to whatever they use, IF they use the same scheme) but don't count on it.
atexit is processed by the C/C++ runtime (CRT). It runs after main() has already returned. Probably the best way to do this is to replace the standard CRT with your own.
On Windows tlibc is probably a great place to start: http://www.codeproject.com/KB/library/tlibc.aspx
Look at the code sample for mainCRTStartup and just run your code after the call to _doexit();
but before ExitProcess.
Alternatively, you could just get notified when ExitProcess gets called. When ExitProcess gets called the following occurs (according to http://msdn.microsoft.com/en-us/library/ms682658%28VS.85%29.aspx):
All of the threads in the process, except the calling thread, terminate their execution without receiving a DLL_THREAD_DETACH notification.
The states of all of the threads terminated in step 1 become signaled.
The entry-point functions of all loaded dynamic-link libraries (DLLs) are called with DLL_PROCESS_DETACH.
After all attached DLLs have executed any process termination code, the ExitProcess function terminates the current process, including the calling thread.
The state of the calling thread becomes signaled.
All of the object handles opened by the process are closed.
The termination status of the process changes from STILL_ACTIVE to the exit value of the process.
The state of the process object becomes signaled, satisfying any threads that had been waiting for the process to terminate.
So, one method would be to create a DLL and have that DLL attach to the process. It will get notified when the process exits, which should be after atexit has been processed.
Obviously, this is all rather hackish, proceed carefully.
This is dependent on the development platform. For example, Borland C++ has a #pragma which could be used for exactly this. (From Borland C++ 5.0, c. 1995)
#pragma startup function-name [priority]
#pragma exit function-name [priority]
These two pragmas allow the program to specify function(s) that should be called either upon program startup (before the main function is called), or program exit (just before the program terminates through _exit).
The specified function-name must be a previously declared function as:
void function-name(void);
The optional priority should be in the range 64 to 255, with highest priority at 0; default is 100. Functions with higher priorities are called first at startup and last at exit. Priorities from 0 to 63 are used by the C libraries, and should not be used by the user.
Perhaps your C compiler has a similar facility?
I've read multiple times you can't guarantee the construction order of global variables (cite). I'd think it is pretty safe to infer from this that destructor execution order is also not guaranteed.
Therefore if your memory tracking object is global, you will almost certainly be unable any guarantees that your memory tracker object will get destructed last (or constructed first). If it's not destructed last, and other allocations are outstanding, then yes it will notice the leaks you mention.
Also, what platform is this _atexit function defined for?
Having the memory tracker's cleanup executed last is the best solution. The easiest way I've found to do that is to explicitly control all the relevant global variables' initialization order. (Some libraries hide their global state in fancy classes or otherwise, thinking they're following a pattern, but all they do is prevent this kind of flexibility.)
Example main.cpp:
#include "global_init.inc"
int main() {
// do very little work; all initialization, main-specific stuff
// then call your application's mainloop
}
Where the global-initialization file includes object definitions and #includes similar non-header files. Order the objects in this file in the order you want them constructed, and they'll be destructed in the reverse order. 18.3/8 in C++03 guarantees that destruction order mirrors construction: "Non-local objects with static storage duration are destroyed in the reverse order of the completion of their constructor." (That section is talking about exit(), but a return from main is the same, see 3.6.1/5.)
As a bonus, you're guaranteed that all globals (in that file) are initialized before entering main. (Something not guaranteed in the standard, but allowed if implementations choose.)
I've had this exact problem, also writing a memory tracker.
A few things:
Along with destruction, you also need to handle construction. Be prepared for malloc/new to be called BEFORE your memory tracker is constructed (assuming it is written as a class). So you need your class to know whether it has been constructed or destructed yet!
class MemTracker
{
enum State
{
unconstructed = 0, // must be 0 !!!
constructed,
destructed
};
State state;
MemTracker()
{
if (state == unconstructed)
{
// construct...
state = constructed;
}
}
};
static MemTracker memTracker; // all statics are zero-initted by linker
On every allocation that calls into your tracker, construct it!
MemTracker::malloc(...)
{
// force call to constructor, which does nothing after first time
new (this) MemTracker();
...
}
Strange, but true. Anyhow, onto destruction:
~MemTracker()
{
OutputLeaks(file);
state = destructed;
}
So, on destruction, output your results. Yet we know that there will be more calls. What to do? Well,...
MemTracker::free(void * ptr)
{
do_tracking(ptr);
if (state == destructed)
{
// we must getting called late
// so re-output
// Note that this might happen a lot...
OutputLeaks(file); // again!
}
}
And lastly:
be careful with threading
be careful not to call malloc/free/new/delete inside your tracker, or be able to detect the recursion, etc :-)
EDIT:
and I forgot, if you put your tracker in a DLL, you will probably need to LoadLibrary() (or dlopen, etc) yourself to up your reference count, so that you don't get removed from memory prematurely. Because although your class can still be called after destruction, it can't if the code has been unloaded.