You should use a debugger to determine where the fault occurs, then take it from there.
But I can easily see that you never set your Glib::RefPtr<Gtk::TextBuffer> textbuffer
to point at anything… so it holds a null pointer, and a segfault is completely predictable.
A RefPtr
is just that, a pointer, and you must ensure it points at some instance before using it. It’s not like non-pointer Gtk::Widget
subclasses, which create/wrap the instance for you, so you have one even if calling the default constructor. Instead, a default-constructed RefPtr
points at nothing, so you can’t dereference as you did. So you cannot just declare and use RefPtr
s like ‘value’ Widget
s and hope for the best; they are not the same.
Since the TextView
default constructor creates and uses its own TextBuffer
, you can just initialise your member RefPtr
like so:
Glib::RefPtr<Gtk::TextBuffer> textbuffer{ m_textArea.get_buffer() }
then it will actually point at an instance, i.e. the buffer created by the view, and so it will be valid to dereference.
But to be honest you probably don’t even need a member, can just do m_textArea.get_buffer()->FOO()
whenever you need it.
If for any reason you wanted to create a separate TextBuffer
, you would use an instance Gtk::TextBuffer::create()
. All Glib::Object
derived classes will provide a create()
method that will return a valid, dereferencable RefPtr
of their type (unless that class can only be retrieved from another class, factory, etc.)
Start here in the docs and that should explain most of what you could want to know about using RefPtr
s. Beyond that, I suggest having a go at using gdb
or another debugger, and that will empower you to fix your own bugs. 