I have a simple doubly linked list for a class I am in and I keep getting a seg fault on my last line of code, no matter what i make it. I can put a bunch of random couts and it will print them all then on the last one seg fault, all my test functions are working how they should too. Any idea what would cause a seg fault? only things in the class are what my prof says are the typical functions... The big 3, popBack/front, pushback/front and a few others that already work as they should... Only thing i can think of is the destructor causing a seg fault. the destructor just calls my popback function which the code for is below...could this be the problem? any help is appreciated.

void Dll11List::popBack(){
	Dll11Node* nodeptr;
	if(isEmpty()){
		cerr<<"\nList is Empty";
		return;
	}
	if(_first->_fore == NULL){
		delete _last;
		_first = NULL;
		_last = NULL;
	}else{
		nodeptr = _last->_back;
		delete _last;
		_last = nodeptr;
	}
	--_size;
}

Dani AI

Generated

Quick diagnosis and focused checks (grounded in the thread): the most likely root cause is a dangling pointer left after removing the tail. 's destructor calls the pop-back loop, showed the "temporary tail" idea, highlighted the 2-element case, and correctly pointed to memory corruption — combine those and the usual recipe is: when the old tail is deleted, the new tail's forward link must be cleared and list invariants must be preserved.

Concrete checklist to apply (no fluff):

  • After moving _last to the previous node, set the new _last->_fore to NULL. If the list becomes empty, make sure both _first and _last are NULL and _size == 0.
  • Verify isEmpty() and _size agree (one canonical source of truth).
  • Confirm pushFront/pushBack set both links correctly when inserting the first node. A bad insertion routine corrupts later deletions.
  • Double-check the copy constructor and assignment operator perform deep copies; a shallow copy will produce double-deletes in the destructor.

Quick debugging steps that usually pinpoint the fault:

  • Run under Valgrind (memcheck) or AddressSanitizer to catch invalid reads/writes and double-free.
  • Build with -g and use gdb to get a backtrace at the crash; the trace usually shows the destructor path.
  • Add invariant assertions and small pointer prints inside popBack to see addresses before/after deletion:
assert((_first == NULL) == (_last == NULL));
if (_last) assert(_last->_fore == NULL);
if (_first) assert(_first->_back == NULL);

A robust pop-back sequence (conceptually) is: save prev = tail->back, delete tail, set tail = prev, if tail then tail->_fore = NULL else set head = NULL, decrement size. Applying these checks and running the program under Valgrind will almost always expose whether the problem is a forgotten pointer update, an earlier buffer overwrite, or a double-delete from a bad copy.

Recommended Answers

All 6 Replies

DllllNode* temporaryTail = _last;

    _last = _last->_back;

    delete temporaryTail;

I tried these changes and its still giving me a seg fault on the last line of code. maybe thats not the problem. What else could cause a seg fault on the last line of code no matter what that line of code is?
Thanks

What else could cause a seg fault on the last line of code no matter what that line of code is?

Corrupted memory that only manifests in the destructor is a good start.

Think of the case of a list with 2 elements. Once you've deleted the last one, where does _first->_fore point to?
BTW, same applies to _last->_fore in a general case.

well thats what i was thinking, but the destructor calls a function called delAll0() which simply calls the popback function which the code for is above, its supposed to delete the last node. i have a loop as well that says while(!isEmpty) then just called the popBack function. can you see anything wrong with the popBack function?

I am just really confused on this because the way my prof does things ive never done them this way before...I am assuming my function is mostly right since that is what my prof gave us in class for the popBack function but I just dont see how to fix it. any help is great.
Thanks

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.