A few days ago, the application version was released to integrate various modules, including libraries related to file management and video recording services.
Background: When file management is initialized, the application layer specifies the data root directory.
The test found that when a specific operation is performed, the directory is invalid and the file cannot be created. The log is probably like (NULL) /Movie/xxxx.MP4, as if the specified root directory has become empty.
After checking, I did not deinitialize, I communicated with the colleague in charge of the file management library remotely, and he maintained a pointer in the library to point to the directory string set by the application layer (of course, this method is not good, it should be copied in, and later Revise),
After confirming that the application layer has not changed the contents of this root directory, it is certain that this pointer has been modified to NULL at some point.
Use the arm-xxxx-nm command to check the symbol table of the relevant file management .a static library (without using the .so library), and find that the data segment has the pointer RootDir and its address. In order to detect who modified this pointer variable,
After compiling the program, use arm-xxx-gdb to start the program, watch RootDir before starting, and then perform the operation that triggers the exception, and then it is gratifying to see that there is indeed a place to change this pointer to 0. Sadly, when the watch stops , the code has been run, and it is impossible to find out which code has modified it. After running it many times, it is found that the place where it stops is different each time.
It is not clear why it is not stopped when this variable is modified, it may be related to multi-threading.
To continue to solve the problem, at this time, we can only use the violent method + print:
First look at the symbolic address of the RootDir variable in the execution program, use arm-xxx-nm app to get its runtime address, such as 0x40008008,
Then analyze the possible code paths that trigger NULL, insert multiple prints in these codes, print *(unsigned int*) 0x40008008, which is the address stored in RootDir, and see under what circumstances it becomes 0, from non-0 to 0 The code in between is probably the place to stomp on memory.
(There may be a problem here. After inserting the print statement, the address of RootDir may change, so after compiling, use the nm command to check whether the address of RootDir is still 0x40008008. If not, change 0x40008008 in the print statement to a new address. , compile again, it should be consistent after this)
Then use a similar dichotomy method to gradually narrow the detection range until a video-related function is located. Before this function, RootDir has a normal value. After this function is executed, the address recorded by RootDir becomes 0, and 99% can be determined to be caused by this function. question.
Since this function is a library function provided by other components, it should be checked by the relevant person in charge. The final reason is that the array operation is out of bounds and a large piece of memory is stepped on. Why do you step on RootDir? This is a global variable. After compiling into the final executable program, from the address point of view, it is adjacent to the related array, and then it is harmed. . .