CareerCup

By corrupt are we meaning one of the following, or all of the following

(1) There is a cycle in the linked list
(2) The next pointer is pointing to garbage (instead of pointing to a valid node or being NULL in case it is the tail node)

Are there any more ways in which a singly linked list can be corrupt ?

cycle is allowed (It can be a circular list).

One of the nodes could point to a node that's been freed.

Take two pointers to the head. Increase the first to 1 and second to the double of the first.

They would meet each other if the one of the nodes has a circular reference.

To Jack, In case we have a pointer pointing to a node that has already been freed, then we will encounter a "segmentation fault". but i don't know how are you going to detect such corruption beforehand?

If you free a node, the system marks the space as unused but the data is still intact.

A seg fault would occur if you tried to access the kernel space, dereference a null pointer, etc. Basically, any illegal memory access.

You can calculate the hash of the data in the list each time new node being added.

First you calculate hash code of Nth first elements (without new node). If it's different from old know hash code, then the list is corrupted. If it's not, remember the new hash of N+1 nodes.

Every modification of the list should proceed after the recalculation of the old hash :).

Not really good performance here. O(N) for each simple operation, but original requirements was ambiguous.

let ptr is pointer assigned address to head
then
while(!hash(ptr)&&!ptr)
ptr=ptr->next;

Gayle Any Comments?

You can detect memory corruption if only you have put some signature in front of every node while creating the linked list. In that you can verify the signature of each node and if signature is not correct then node is corrupted.

how do we check this programatically

This is a really good interview question. The reason is that linked lists are used in a wide variety of scenarios and being able to detect and correct pointer corruptions might be a very valuable tool. For example, data blocks associated with files in a file system are usually stored as linked lists. Each data block points to the next data block. A single corrupt pointer can cause the entire file to be lost!





Discover and fix bugs when they corrupt the linked list and not when effect becomes visible in some other part of the program. Perform frequent consistency checks (to see if the linked list is indeed holding the data that you inserted into it).

It is good programming practice to set the pointer value to NULL immediately after freeing the memory pointed at by the pointer. This will help in debugging, because it will tell you that the object was freed somewhere beforehand. Keep track of how many objects are pointing to a object using reference counts if required.

Use a good debugger to see how the datastructures are getting corrupted and trace down the problem. Debuggers like ddd on linux and memory profilers like Purify, Electric fence are good starting points. These tools should help you track down heap corruption issues easily.

Avoid global variables when traversing and manipulating linked lists. Imagine what would happen if a function which is only supposed to traverse a linked list using a global head pointer accidently sets the head pointer to NULL!.

Its a good idea to check the addNode() and the deleteNode() routines and test them for all types of scenarios. This should include tests for inserting/deleting nodes at the front/middle/end of the linked list, working with an empty linked list, running out of memory when using malloc() when allocating memory for new nodes, writing through NULL pointers, writing more data into the node fields then they can hold (resulting in corrupting the (probably adjacent) "prev" and "next" pointer fields), make sure bug fixes and enhancements to the linked list code are reviewed and well tested (a lot of bugs come from quick and dirty bug fixing), log and handle all possible errors (this will help you a lot while debugging), add multiple levels of logging so that you can dig through the logs. The list is endless...

Each node can have an extra field associated with it. This field indicates the number of nodes after this node in the linked list. This extra field needs to be kept up-to-date when we inserte or delete nodes in the linked list (It might become slightly complicated when insertion or deletion happens not at end, but anywhere in the linked list). Then, if for any node, p->field > 0 and p->next == NULL, it surely points to a pointer corruption.

You could also keep the count of the total number of nodes in a linked list and use it to check if the list is indeed having those many nodes or not.



The problem in detecting such pointer corruptions in C is that its only the programmer who knows that the pointer is corrupted. The program has no way of knowing that something is wrong. So the best way to fix these errors is check your logic and test your code to the maximum possible extent. I am not aware of ways in C to recover the lost nodes of a corrupted linked list. C does not track pointers so there is no good way to know if an arbitrary pointer has been corrupted or not. The platform may have a library service that checks if a pointer points to valid memory (for instance on Win32 there is a IsBadReadPtr, IsBadWritePtr API.) If you detect a cycle in the link list, it's definitely bad. If it's a doubly linked list you can verify, pNode->Next->Prev == pNode.


I have a hunch that interviewers who ask this question are probably hinting at something called Smart Pointers in C++. Smart pointers are particularly useful in the face of exceptions as they ensure proper destruction of dynamically allocated objects. They can also be used to keep track of dynamically allocated objects shared by multiple owners. This topic is out of scope here, but you can find lots of material on the Internet for Smart Pointers.

If you have better answers to this question, let me know!