While debugging a piece of code I see this on gdb:
(gdb) p *(input_t *) 0xec08b4d0
$25 = {
count = 0xec0644ec,
data = std::shared_ptr (expired, weak 0) 0xec0913ec,
}
Assignment to data leads to a crash. Is data an invalid pointer ?
Related
Thread [1] (STOPPED) (Suspended : Signal : SIGSEGV:Segmentation fault)
_block_mem_malloc_align() at 0xb8206f4f
_band_get_aligned() at 0xb820709f
_band_get() at 0xb82071e6
__malloc_lock() at 0xb820fa15
__malloc() at 0xb820fb28
_malloc() at 0xb8205d0b
malloc_allocator() at 0xb821975d
debug_allocator() at 0xb8219148
__debug_malloc() at 0xb8219799
mtrace_malloc() at 0xb821b9df
debug_malloc_l() at 0xb82196a6
operator new() at 0xb8208c66
During call to the new operator, it causes SIGSEGV, however, it the stack trace I'm unable to pinpoint which address new tries to give when it raises exception.
In the code snippet below:
int main(){
CheckedPtr<int> aa = new int[4];
aa[0] = 2;
aa[1] = 2;
aa[2] = 2;
aa[3] = 2;
aa[4] = 2;
aa[5] = 1; //0x8084604 overflow
CheckedPtr<CustomObject> bb = new CustomObject; //0x8088084
}
During call to the constructor, it overwrites the region 0x8084604 with some values and it did not crash. But somewhere inside the [CustomObject] where [new] is called it crashes. However, I can not pinpoint that [0x8084604] is causing the crash itself. Im hoping my question is clear.
I would like to access the data pointer for a pybind11::array_t<T> typed NumPy array wrapper, while stepping in a debugger. As below, the debugger does not know the type of array_t<T>, so the data(...)/mutable_data(...) accessors are not available.
(lldb) p o
(pybind11::array_t<unsigned long long, 16>) $24 = {
pybind11::array = {
pybind11::buffer = {
pybind11::object = {
pybind11::handle = (m_ptr = '0x10872fe40')
}
}
}
}
(lldb) p o.data()
error: no member named 'data' in 'pybind11::array_t<unsigned long long, 16>'
(lldb) p o.data(0)
error: no member named 'data' in 'pybind11::array_t<unsigned long long, 16>'
Based on the implementation of array_t::data in pybind11's numpy.h, a solution is to use the pybind11::detail::array_proxy to access the data pointer:
(lldb) p ((uint64_t*)pybind11::detail::array_proxy(o.m_ptr)->data)[652]
(uint64_t) $26 = 87112
I debug Chrome in gdb and I run into this problem all the time:
If I try to print a variable of certain type, GDB does not know its internals:
(gdb) p current_child_.get()
$12 = (blink::NGBlockNode *) 0xc2f755c1830
(gdb) p *(current_child_.get())
$13 = <incomplete type>
But, if I just set a breakpoint in a constructor of that class, gdb will suddenly discover that type's symbols:
(gdb) br blink::NGBlockNode::NGBlockNode
Breakpoint 3 at 0x51db40 (4 locations)
(gdb) p *(current_child_.get())
$14 = {
<blink::NGLayoutInputNode> = {
<blink::GarbageCollectedFinalized<blink::NGLayoutInputNode>> = {
<blink::GarbageCollected<blink::NGLayoutInputNode>> = {<No data fields>}, <No data fields>},
This is so annoying, I have a set of macros to set breakpoints in classes I usually print. Are there any other workarounds?
I know one workaround. If you know the file which defines the type, you can force loading debug information of that type, by "print 'file.cc'::some_variable". If this "some_variable" actually exists or not does not really matter.
e.g.
(gdb) p render_thread
$2 = (content::RenderThreadImpl *) 0x1261201f7920
(gdb) p *render_thread
$3 = <incomplete type>
(gdb) ptype render_thread
type = class content::RenderThreadImpl {
<incomplete type>
} *
(gdb) p 'render_thread_impl.cc'::nonexist_variable
No symbol "nonexist_variable" in specified context.
(gdb) ptype render_thread
type = /* real type = content::RenderThreadImpl * */
class content::RenderThreadImpl : <snipped> {
<snipped>
} *
(gdb) p *render_thread
$4 = (content::RenderThreadImpl) { <snipped> }
(gdb)
Turns out that the root cause is my compile flags: using gcc --gdb-index and --split-dwarf options together results in corrupt debug information. – Aleksandar Totic
I'm working on a C++ program that should be able to run for several days, so it is a bit of a hassle that its memory consumption seems to grow really fast.
The full code of the program is a little long, so I'll post just the related things. The structure is the following:
int main (void){
//initialization of the global variables
error = 0;
state = 0;
cycle = 0;
exportcycle = 0;
status = 0;
counter_temp_ctrl = 0;
start = 0;
stop = 0;
inittimer();
mysql_del ("TempMeas");
mysql_del ("TempMeasHist");
mysql_del ("MyControl");
mysql_del ("MyStatus");
initmysql();
while(1){
statemachine();
pause();
}
}
The timer function that is initialized above is the following:
void catch_alarm (int sig)
{
//Set the statemachine to state 1 (reading in new values)
start = readmysql("MyStatus", "Start", 0);
stop = readmysql("MyStatus", "Stop", 0);
if (start == 1){
state = 1;
}
if (stop == 1){
state = 5;
}
//printf("Alarm event\n");
signal (sig, catch_alarm);
return void();
}
So basically, since I'm not setting the start bit in the webinterface that modifies the MyStatus Tab the program just calls the readmysql function twice every second (the timer's interval). The readmysql function is given below:
float readmysql(string table, string row, int lastvalue){
float readdata = 0;
// Initialize a connection to MySQL
MYSQL_RES *mysql_res;
MYSQL_ROW mysqlrow;
MYSQL *con = mysql_init(NULL);
if(con == NULL)
{
error_exit(con);
}
if (mysql_real_connect(con, "localhost", "user1", "user1", "TempDB", 0, NULL, 0) == NULL)
{
error_exit(con);
}
if (lastvalue == 1){
string qu = "Select "+ row +" from "+ table +" AS a where MeasTime=(select MAX(MeasTime) from "+ table;
error = mysql_query(con, qu.c_str());
}
else{
string qu = "Select "+ row +" from "+ table;
error = mysql_query(con, qu.c_str());
}
mysql_res = mysql_store_result(con);
while((mysqlrow = mysql_fetch_row(mysql_res)) != NULL)
{
readdata = atoi(mysqlrow[0]);
}
//cout << "readdata "+table+ " "+row+" = " << readdata << endl;
// Close the MySQL connection
mysql_close(con);
//delete mysql_res;
//delete mysqlrow;
return readdata;
}
I thought that the variables in this function are stored on the stack and are freed automaticaly when leaving the function. However it seems that some part of the memory is not freed, because it just grows after all. As you can see I have tried to use the delete function on two of the variables. Seems to have no effect. What am i doing wrong in terms of memory-management and so on?
Thanks for your help!
Greetings Oliver.
At least mysql_store_result is leaking. From documentation:
After invoking mysql_query() or mysql_real_query(), you must call mysql_store_result() or mysql_use_result() for every statement that successfully produces a result set (SELECT, SHOW, DESCRIBE, EXPLAIN, CHECK TABLE, and so forth). You must also call mysql_free_result() after you are done with the result set.
If your program continuously consumes memory (without ever releasing it), then you have a memory leak.
A good way to detect memory leaks, is to run it through a memory debugger, e.g. valgrind:
$ valgrind /path/to/my/program
Once your program started eating memory, stop it and valgrind will give you a nice summary about where your program allocated memory that was never freed.
There is no need to let the system run out of memory and crash; just wait until it has eaten some memory that has not been freed. Then fix your code. Then repeat until no more memory errors can be detected.
Also note that valgrind intercepts your systems memory management. This usually results in a (severe) performance penalty.
i have this code. the pointer turns 0x0 immediately before using it. short before, it had the correct address.
TreeViewColumn *col;
col = preview->get_column(pcFolder); /* col = 0x7fff5fc404a0 */
col->set_resizable(true); /* col = 0x0 */
i use Gtkmm 2.4, but it returns the expected value, it just turns 0x0. whats wrong?
gdb proof:
151 col = preview->get_column(pcFolder); /* col = 0x7fff5fc404a0 */
(gdb) print col
$1 = ('Gtk::TreeViewColumn' *) 0x7fff5fc404a0
(gdb) print *col
warning: can't find linker symbol for virtual table for `Gtk::TreeViewColumn' value
$2 = {
<Gtk::Object> = {
<Glib::Object> = {
<Glib::ObjectBase> = <invalid address>,
members of Glib::Object:
_vptr$Object = 0x7fff5fc06a20,
static object_class_ = {<No data fields>}
},
members of Gtk::Object:
static object_class_ = {<No data fields>},
referenced_ = 21,
gobject_disposed_ = 60
},
members of Gtk::TreeViewColumn:
static treeviewcolumn_class_ = {<No data fields>}
}
(gdb) next
152 col->set_resizable(true); /* col = 0x0 */
(gdb) print col
$3 = ('Gtk::TreeViewColumn' *) 0x0
(gdb) print *col
Cannot access memory at address 0x0
(gdb) next
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001000edc68 in Gtk::TreeViewColumn::set_resizable ()
i have no idea what causes this phenomenon. do you have?
Solution:
reading the documentation. the function returning pcFolder counts from 1, get_column() from 0.
The function call:
preview->get_column(pcFolder);
returns NULL.
When gdb shows the current code line, it hasn't been executed until you type next.
You probably pass an index that is larger than the number of columns in preview. Try:
p pcFolder
p preview->get_columns().size()
preview->get_column(); returns NULL, before that, its just some random value, since you didn't initialize the col variable
Better code would actually be to initialise the variable immediately on use by calling getColumn at the point of declaration:
TreeViewColumn *col = preview->get_column(pcFolder);
If this function can return NULL (as it appears to) you must then check before you use the pointer, thus:
if( col != NULL )
{
col->set_resizable( true );
}
// else handle the "error" if you want
preview->get_column(pcFolder)
must be returning 0.