Thank you both for your replies. I had hoped that the problem would have a simple solution, ie: "don't ever do sorting without a proxy model". That not being the case, I will start to transfer my code into a minimal compilable example, if the cause of the problem does not reveal itself in the process, i'll post it here.

What do you mean, a segfault occurs in the block of code between beginRemoveRows() and endRemoveRows() or in a slot connected to beginRomoveRows()?
The segfault occurs in the stack resulting from a call to the beginRemoveRows()-method. The execution goes via the QAbstractItemModelPrivate::rowsAboutToBeRemoved(.. .)-method and segfaults when a call to parent() returns a QModelIndex with an invalid internalPointer. Invalid because the cast to a Node results in an invalid node that then accesses illegal memory.

This makes me assume that the pointer to the parent Node (application specific management item) is stored in any given QModelIndex's internal pointer, am I correct? Further just having pointer to a valid parent (Node) is not enough, what I mean is having the pointer to the correct parent is very essential. Further I wonder how can you be confident about creating nodes with pointers to valid parents when segfault occurs?
Your assumption is correct. The problem i'm having is that the pointer no longer seems to point to a true Node-object, which is strange considering that whenever i create a QModelIndex i set the internalPointer to a valid Node or return an invalid index. Perhaps the model is calling the createIndex-method on its own with some other pointers but my code shouldn't be.

1. Check beginRemoveRows() parameters, there is a potential that the parameters are not valid. (As this is where you see a segfault)
2. Indexes are created (I mean in index() method) in a fool proof manner (i.e. all possible parameters values are handled properly)
3. Are you using any persistent indexes, or storing any indexes? If yes then better review them.
I will check these points first and foremost. Regarding point 3, the crash in rowsAboutToBeRemoved is doing a loop over persistent indexes. I have not done anything with these directly. Should i be modifying persistent indexes? I don't really know what they are so this could very well be an oversight on my part.

Thanks again for your replies, I hope my clarifications thus far have given some additional insigt and will be complementing with more information shortly.

best regards,
TR