Seg fault when deleting Q3DScatter object

JonB

@vedranMv
Why are you in the Disassembler pane? I think use the up/down arrows there to pick the "stack trace" pane? Find & show that, even if it turns out the stack is corrupted (which can happen), at least let's see the appropriate pane. I don't recognise your layout/the top pane, but then I am Qt Creator/gdb/gcc under Linux.

vedranMv

@JonB Thanks for suggestion. That's where I'm taken when fault happens. I guess it means that fault is thrown in some of the libraries, which can't be tracked? If I use the left/right arrows, I get taken back to another dissasembly screen when pressing left arrow for the first time, then back to whatever document I edited the last, when pressed for the second time.

I have been playing with destructor of ScatterPlot class. If I leave it empty or make it like this, I get seg fault:

ScatterPlot ::~ScatterPlot ()
{
      m_graph->seriesList().clear();
      m_graph->close();
      m_graph->deleteLater();
}

If I instead directly call m_graph's destructor, seg fault is not happening.

ScatterPlot ::~ScatterPlot ()
{
      m_graph->seriesList().clear();
      m_graph->close();
      m_graph->~Q3DScatter();
}

SGaist

Hi,

Might be a silly question but are you sure you are using a debug build ?

vedranMv

@SGaist Thanks, I don't mind revisiting the basics :) I am running a debug build and if I force a fault in my part of the code, I get output as expected with a fault point in code and stack trace underneath

JonB

@vedranMv
So now you do have the stack trace pane which you said you couldn't get at!

It's dumping inside QComboBox::currentText(). For SIGSEGV I would check in debugger what your *X is, taken from your inCh, for validity.

vedranMv

@JonB No, this is an example to show that normally I am able to see the stack trace. This was provoked on purpose. But thanks :)

When the original segfault happens, this window remains empty as shown above

vedranMv

I have uploaded the code to github, in case anybody is interested in trying it out: https://github.com/vedranMv/dataDashboard/

There's a branch called segfault which in combination with the description above creates the fault. To recap, steps are:

Run the app
In the Dashboard tab press "Add 3D" button
In the Dashboard tab press "Add scatter" button
Press 'X' to close scatter window
Enjoy the segfault

There's also what I believe is a fix, but I'd like to understand why it works. Documentation and general recommendation is to use deleteLater() instead, but that also results in a segfault :)

JohanSolo

Ouch, that hurts! Why do you explicitly call the destructor?
If you do want to free the memory (and do you?) use delete _graph. Did you set a parent to your Q3DScatter instance? If you did, then it will be deleted for you.

Edit:
@vedranMv said in Seg fault when deleting Q3DScatter object:

There's also what I believe is a fix, but I'd like to understand why it works. Documentation and general recommendation is to use deleteLater() instead, but that also results in a segfault :)

Then it means you're most probably deleting twice the instance: the first time with your dicey call to the destructor / or deleteLater, and the second when the parent object gets deleted.

vedranMv

@JohanSolo Thanks, I for some reason did not think of using delete here at all :D That works just as good!

Regarding your edit, what you're writing makes perfect sense, but as you can see in the code, it's the other way around. If I don't call delete manually, I get a segfault. And yes, object gets a parent because I encapsulate it into a container widget, which is then added into the UI window.

JohanSolo

@vedranMv said in Seg fault when deleting Q3DScatter object:

Regarding your edit, what you're writing makes perfect sense, but as you can see in the code, it's the other way around. If I don't call delete manually, I get a segfault.

Then it seems to me there must be something else wrong in your code.