parameter value lost after call new_allocator in c++ - c++

Question

I meet a strange behavior for a c++11 program, and can not figure out what is going wrong. please gave me some advises. thanks.
basically, it is a OpenCL program.
struct memory_layout
{
public:
memory_layout(managed_device d);
scalar<int> s;
};
memory_layout::memory_layout(managed_device d) :
s(d)
{
}
class doer
{
public:
doer();
void go();
private:
managed_device dev;
memory_layout mem;
};
doer::doer():
dev(find_CPU()),
mem(dev)
{
}
void doer::go()
{
task t = copy(10,mem.s);
}
int main(){
doer d;
d.go();
return 0;
}
when it runs to copy function, it has "Segmentation Fault".
Here is the def of copy:
template <typename T>
task copy(const T& source, scalar<T>& sink, const std::vector<task>& deps = {} )
{
return sink.device().create_task( profile::copy<T>(source, sink), deps );
}
When I use gdb to debug:
Breakpoint 1, doer::go (this=0x7fffffffdc90) at main.cpp:79
79 task t = copy(10,mem.s); // device() original be 0x60f0d0
(gdb) p mem.s.device()
$1 = (cppcl::opencl_1_2::device::managed_device &) #0x7fffffffdc60: {_device = 0x60f0d0}
(gdb) s
std::vector<unsigned long, std::allocator<unsigned long> >::vector (this=0x7fffffffdc50) at /usr/include/c++/4.8.3/bits/stl_vector.h:249
249 : _Base() { }
(gdb)
std::_Vector_base<unsigned long, std::allocator<unsigned long> >::_Vector_base (this=0x7fffffffdc50)
at /usr/include/c++/4.8.3/bits/stl_vector.h:125
125 : _M_impl() { }
(gdb)
std::_Vector_base<unsigned long, std::allocator<unsigned long> >::_Vector_impl::_Vector_impl (this=0x7fffffffdc50)
at /usr/include/c++/4.8.3/bits/stl_vector.h:87
87 : _Tp_alloc_type(), _M_start(0), _M_finish(0), _M_end_of_storage(0)
(gdb)
std::allocator<unsigned long>::allocator (this=0x7fffffffdc50) at /usr/include/c++/4.8.3/bits/allocator.h:113
113 allocator() throw() { }
(gdb)
__gnu_cxx::new_allocator<unsigned long>::new_allocator (this=0x7fffffffdc50) at /usr/include/c++/4.8.3/ext/new_allocator.h:80
warning: Source file is more recent than executable.
80
(gdb)
std::_Vector_base<unsigned long, std::allocator<unsigned long> >::_Vector_impl::_Vector_impl (this=0x7fffffffdc50)
at /usr/include/c++/4.8.3/bits/stl_vector.h:88
88 { }
(gdb)
cppcl::opencl_1_2::device::copy<int> (source=#0x7fffffffdc6c: 10, sink=..., deps=std::vector of length 0, capacity 0)
at /usr/include/cppcl/1.2/device/buffer_templates.h:1233
warning: Source file is more recent than executable.
1233 return sink.device().create_task( profile::copy<T>(source, sink), deps );
(gdb) p sink.device()
$2 = (cppcl::opencl_1_2::device::managed_device &) #0x7fffffffdc60: {_device = 0x0}
after I step into the copy function, it first build the "deps" parameter, and then, the _device value changed to 0x0. I could not figure out why this happy?
thanks for giving me some suggestions.

Answer 1

I'm assuming that you're not asking what's wrong with your code, that you're only asking how to figure out yourself what's wrong with your code. Otherwise, there's not enough information in your question.
This is a good first step in debugging. You've found clear indication that one value in memory is being changed. You've found a concrete object managed_device at address 0x7fffffffdc60 that contains a value that gets changed somehow.
Let me use a simple complete program:
#include <stdio.h>
int *p;
void f() {
++*p;
}
int main() {
int i = 3;
p = &i;
printf("%d\n", i); // i is 3 here.
f();
printf("%d\n", i); // Huh? i is 4 here.
}
Now, of course it is completely and utterly obvious why i changes in this program, but let's suppose that I completely overlooked it anyway.
If I set a breakpoint on line 13 (the call to f), and inspect i, I see that it is still 3.
Breakpoint 1, main () at test.cc:13
13 f();
(gdb) p i
$1 = 3
No surprise there. And I've already determined that the value will at some unknown point in the future get changed, I just don't know when.
I can now use the watch instruction to monitor that variable for changes:
(gdb) watch i
Hardware watchpoint 2: i
and then continue execution:
(gdb) cont
Continuing.
Hardware watchpoint 2: i
Old value = 3
New value = 4
f () at test.cc:7
7 }
(gdb) bt
#0 f () at test.cc:7
#1 0x004011e9 in main () at test.cc:13
Now, I have seen that the code that modified i was just before the closing brace in f.
This is what you'll need to do with your own code. It'll be a bit more complex than in this simple example, but you should be able to use it for your own code as well.