There was a strange problem yesterday, and the third party engine came up with a new search-and-seek library, the original implementation is a static link library (. A), but the new version changed to Dynamic Link (. So), I did not think so much, directly in the need of the place Dlopen open the so, who knows that a run to this sentence on the program. Using GDB to view core files, the top stack is roughly:
#0 _dlerror_run ()
#1 Dlopen ()
Google a "_dlerror_run crash", "_dlerror_run crash" and other keywords, so I tried to load the library elsewhere, for example, I in the main function in the first few lines to load the library, found that can be successful, no error.
Later this matter because I have other things to do, temporarily to the Montana NIU brother to see. NIU uses the binary method to determine which line of code to call and then load the library will result in crash, finally determined in the Pthread_setspecific function. This results in the discovery that Pthread_key_create was not invoked before pthread_setspecific, causing thread-local storage to be used without initialization. Also, such an operation would affect other so loads.
Later talking to NIU about how to position the problem, Niu said that this problem can only be found in the code binary, constantly changing places to insert the code may cause downtime, and finally determine which function call after the code will be called to downtime.
This kind of problem is seldom encountered, but it makes people very mad. The experience of solving this problem is very valuable and is hereby recorded.