Recently a colleague engaged in compiling environmental transport, to run into a problem, let me help him look.
He built a new directory, then copy the code now past, when the compiler can not find a file compiled execution appeared a core, did not know what the situation.
I went to his build environment, perform make, and she appeared in core files.
Use the file command analysis found that the program is a core proc. So use gdb, I want to go see where the core.
But where the use of open command, find the name of the function outputs are all question marks. According to experience, this is usually due to memory function stack information leading to cross-border destroyed.
So I want to try in the execution of the program inside gdb, see if I can catch the core site.
Use make -n, the actual output of the compiler command. Then use gdb run porc, set the operating parameters, run the program.
After running sigsegv error soon, then use the where command, function stack information is also found.
However, the function name is very strange, is not a library function, not any source, from the name of the function also can not see how the specific cause of the error. So off the idea of using gdb to find a reason.
Then I thought, there are some files compiled successfully, but some files fail to compile. This will not be .pc file if there is any code that triggered the proc bug in it?
So I put the code inside the file deletion, and then compilation.
But no matter how I delete, run a pre-compiled proc will coredump. Description Code should not be a problem.
Is it caused by file name?
So I put the error code recovery, and renamed it the name of another code files can be compiled into. And then compile a try and found operational.
Then I find a code successfully compiled, use the mv command to rename it into code name failed, find precompiled appears core.
After these two tests, it can determine the file name led to the emergence of proc coredump. Observe the successes and failures of the code file name, find the length of the relatively large difference.
Could it be that the file name length is causing it?
So I passed the test and gradually increase the file name, positioning slowly, finally found proc will be abnormal in iname parameters over 100 characters of the time.
Because my colleagues in the new directory path is too long, resulting in the path name + file name exceeds 100 characters, before the old compiler environment directory path is short, so did not find the problem.
Since there is no reservation site, we can not show the appropriate action shots. This article is to introduce a common problem Locator ideas:
1 analysis directly from the results, look at core files, error logs, if there is a clear question where the
2 1 If not, you need to tease out the running step, guessing at that step problems arise. This step is skipped or simplified see if the problem can reproduce. If you can guess the correct instructions, such as not continue other speculation.