Linux Debugging (Eight): is the core really that hard to track?

It's typical to meet several cores this week. Here to share with you.

People who believe they have experience in Linux programming must have met. Feel a lot of people around the core has a natural fear, especially for the new students. Of course, there have been jobs for several years to see the core also helpless. Analysis today, core, in fact, most of them are easy to solve. If a core is difficult to reproduce, then the description is still very complex, is a corner case, it may take a long time, the brain to have a good running state can be (read the source code, learning is the logic, the source of the corresponding to the state of the runtime, analysis of some state machine conversion, To analyze what might happen). I believe that the previous articles will lay a better foundation for the analysis and resolution of this corner case.

On the other hand, a case that has a very high rate of recurrence or repetition is very easy to solve.

multithreading inevitably out of the core?

If your newly added code introduces the core, it's actually very easy to solve, simply compare the changes to the diff and see if there are any lower-level errors. If you can't find it, see if it's a multithreaded problem? If a single thread does not have a core, and the core is changed to multi-threaded, then the multi-threaded competition for certain variables: at the same time modify some variables cause problems. At this point you may have the first reaction locked. I am very disgusted with the lock, even if you lock the granularity is small, the scope is small enough, but as long as the lock, it represents a blockage, it represents the maintenance will be very troublesome. Are these shared variables really so worth locking? Can I change to a local variable? If he is a piece of dynamic memory, in order to call an interface do not frequently request to free memory (such as the interface thousands of times per second call), then the initialization time to request a piece of memory is absolutely reasonable: please set it as a thread variable bar. This memory is applied to each thread when it is initialized.

Of course, if you implement a framework or an interface called by a schema, this interface is thread-safe. So you don't seem to be able to control when this thread starts, and how many threads are there, so there's no way out of it?

In fact, there are many methods, for example, you can maintain a corresponding relationship of a "thread" variable in a map

__gnu_cxx::hash_map< pid_t, void *> thread_data_map;void * thread_buffer;std::map<pid_t, void *>::iterator It;lockit = Thread_data_map.find (PID), if (it = = Thread_data_map.end ()) {    //init "thread data"    thread_data_map[ PID] = Create_buffer ();} else {    thread_buffer = It->second;} Unlock

There is a lock that has to be used here. In fact, because the number of threads is limited, this efficiency is fine. This week I implemented an online application with a QPS that can reach 2000 +, and basically the cost of locking is negligible across the call stack.

Of course, a better framework might provide onthreadinit such an interface, so apply thread variables here:

int pthread_setspecific (pthread_key_t key, const void *value);

The function that implements the logic gets the variable:

void *pthread_getspecific (pthread_key_t key);

When do you want to use thread variables? See if there is a write operation on the variable under multi-threading, if there is a need to apply for thread variables (or lock), otherwise the core must be out.

don't bury yourself in a hole:

Today a classmate's core seems to have made an "optimization", saving the time to apply variables.

void Init () {    my_struct * some_var;    ...    Some_var->res = new Some_res;    Some_var->res->set_value1 (some_common_value1);    Some_var->res->set_value2 (some_common_value2);} void * THREAD_FUNC (my_struct * some_var) {         some_var->res->set_value3 (value_3);   ...}

Set_value3 is the reason for a core. This is also a typical multi-threaded case that inevitably out of the core. In fact, RES does not need to apply in advance. Change it to a local variable, with virtually no loss of performance. Of course, if the resource is large, then it's a thread variable.

so how to analyze the core?

In fact, the core of the above scenario, if only from the core itself, may not be a good time to troubleshoot where the problem is, and the location of the core may not be the same, the inevitable scapegoat; for example, invoking a third-party module, which is actually its own global variable, leads to a third-party call stack. Be sure to check that your processing is correct.

Determines whether the calling interface is thread-safe; If you are a colleague, you have to be sure that he is right. Just like today's other core, the caller insists that he writes thread-safe, as if it were not thread-safe, as if the code did not seem to be written, and when he finally found out that the code he wrote was not thread-safe, he asked you what is thread-safe.

So, how do you analyze the core?

First of all, understand the application scenario of core, such as long sentence processing will have core, multithreading will have core, special characters will have core; this QA will give you a clearer explanation. Then through the core call stack to determine the approximate source location.

In front of the source, there is no secret.

You read the source code, it shows the logic, but in your mind, there is a runtime call stack, multi-threaded scheduling;

Of course, still can't solve, begin to get more detailed information from the core! Look at what the parameters of the call stack are, switch a thread to see what other threads of the frame are.

Can't solve it?

Then it is corner case, as long as the application in the core immediately after the start of the line. Remember that the EMC option for a bug is unable to root cause, which is aptly described. At the same time do not forget the self-comfort: yards of many yards, there must be a bug, who can guarantee service 100%?

Linux Debugging (Eight): is the core really that hard to track?