Why emitting signal can cause a segmentation fault?

[CuriousPan]

Working on my project I got stuch with the following issue: emitting one signal results in segmentation fault. I googled the Internet and it turned out that it can the case that objects emitting signals might be not initialised, but it's not true in my case (at least from what I see). What can be the potential problem?

P.S. I'm connecting signal of a member pointer object (which is getting assigned using initialiser list) to one of the slots of the object so there's no way these things can be uninitialised.

[Christian Ehrlicher]

As always - use a debugger and take a look where it crashes, fix it.

[CuriousPan]

@Christian-Ehrlicher, yes, that's what I did. I'll be honest with you, I'm not that experienced in debugging, but during debugging process the program crashes at line 'emit signal()' and debugger directs me to this:

      _GLIBCXX_ALWAYS_INLINE __int_type
      load(memory_order __m = memory_order_seq_cst) const noexcept
      {
	memory_order __b = __m & __memory_order_mask;
	__glibcxx_assert(__b != memory_order_release);
	__glibcxx_assert(__b != memory_order_acq_rel);

	return __atomic_load_n(&_M_i, __m);
      }

[mchinand]

Look at the previous lines in the stack trace to see where it is in your code when the segfault happens. Also, post your code where you emit your signal and of the slot that it's connected to.

[JonB]

@CuriousPan
Need to emphsize what @mchinand has written: you need to look around the debugger's windows/panes till you find the Stack Trace one. It shows which functions were calling which when the crash happened. Look back up till you find it's telling you a line in your code, look at that.