Re: [Crash-utility] regression with System.map handling on 4.14 +?

----- Original Message ----- First question: why are you using the System.map file as a command line argument? It only make sense to do so if vmlinux-4.14.43-1-pserver is *not* the kernel that was running when ps402a-30-dump.201806041421 was generated. Are you rebuilding a similarly-configured kernel in order to try to create something "close" to the kernel that crashed? If that's true, then that is the only reason to use the System.map file of the kernel that crashed. However... Secondly: it appears that your kernel is running with KASLR enabled and the kernel static text/data has been relocated -- where the the debug message shows that _stext has been relocated from ffffffff810000 to ffffffff9e000000. In that case, the crash utility will perform the gdb back-patching of all kernel symbols using the relocation value of 1d000000. However, if you apply the System.map file as a command line argument, it sets the symbol values back to the addresses in the System.map file, which are the original non-relocated addresses compiled into the vmlinux file. So the short answer is -- NEVER use the System.map file unless you cannot access the original vmlinux file and you are trying to simulate it by rebuilding a similarly-configured kernel. But if that is done, KASLR complicates things because the System.map file contains the non-relocated symbol values that were compiled into the vmlinux file. In that case, then I suppose you would have to create a System.map-like file *before* the kernel crashed by copying /proc/kallsyms to a "fake" System.map file. Since the relocation value changes with each boot, it's too late after the crash, and so in that case I don't have any suggestions. Just keep in mind that using a System.map file is somewhat of a desperate override, telling the crash utility to just use the symbol values within it. Dave