How to find an error only at the memory address?

Question

I got a segment error in an object like this:

http_client_reset(struct http_client *client) { if (client->last_req) { /* @client should never be NULL, but weather a valid object, I don't know */ ... } } 

When debugging a core dump file in GDB, the client memory address is 0x40a651c0 . I tried several times and the address is the same.

Then I tried the bt command in GDB:

 (gdb) bt #0 0x0804c80e in http_client_reset ( c=<error reading variable: Cannot access memory at address 0x40a651c0>, c@entry =<error reading variable: Cannot access memory at address 0x40a651bc>) at http/client.c:170 Cannot access memory at address 0x40a651bc 

there is no traceback message, I have grep ed my source code, and there is only one http_client_reset call.

• How to debug such an error through only the memory address ?
• Is there any way to judge that an object is valid before accessing its field (except obj == NULL )?

Answer 1

Debugging credump crash is never black and white. Thus, you will not be able to get an accurate answer to questions regarding coredump debugging. However, most coredump will be associated with programming errors that can be divided into broad areas. I will provide some of these broad areas and some debugging mechanisms that may help you.

---

Failure Programming Error Class

• multithreaded code - check if there is a critical section when accessing shared data. This can lead to data corruption leading to such a malfunction. In your case, you can check the http_client pointer, access this and CRUD - create / read / update and delete.
• Heap damage. In most cases, this would be a correct pointer and incorrect heap processing in another section of code, this could lead to overwriting the actual pointer. Think of an array at and around the pointer location - problems with ABW, etc. They can easily cause this problem.
• Stack Corruption - This is very unlikely, but hard to find. In case you are overwriting the stack data - similarly to the array in the above example - but on the stack, the same problem will occur.

---

Remedies for the root cause of coredump

You need to understand that - technically, coredump is an illegal operation that throws an unhandled exception, resulting in a failure. Since most of them are related to memory processing, a static analysis tool like kloc/PCLint will capture almost 80% of the problems. Then I will run on valgrind/purify and will most likely reveal the rest of the problem. Very few problems were missed by both of them - this will be some sequence / time code that can be found using code review .

NTN!