Sunday, March 20, 2022

[SOLVED] Configure kern.log to give more info about a segfault

March 20, 2022 debian, kernel, linux, logging, segmentation-fault

Issue

Currently I can find in kern.log entries like this:

[6516247.445846] ex3.x[30901]: segfault at 0 ip 0000000000400564 sp 00007fff96ecb170 error 6 in ex3.x[400000+1000]
[6516254.095173] ex3.x[30907]: segfault at 0 ip 0000000000400564 sp 00007fff0001dcf0 error 6 in ex3.x[400000+1000]
[6516662.523395] ex3.x[31524]: segfault at 7fff80000000 ip 00007f2e11e4aa79 sp 00007fff807061a0 error 4 in libc-2.13.so[7f2e11dcf000+180000]

(You see, apps causing segfault are named ex3.x, means exercise 3 executable).

Is there a way to ask kern.log to log the complete path? Something like:

[6...] /home/user/cclass/ex3.x[3...]: segfault at 0 ip 0564 sp 07f70 error 6 in ex3.x[4...]

So I can easily figure out from who (user/student) this ex3.x is?

Thanks! Beco

Solution

The short answer is: No, it is not possible without making code changes and recompiling the kernel. The normal solution to this problem is to instruct your students to name their executable <student user name>_ex3.x so that you can easily have this information.

However, it is possible to get the information you desire from other methods. Appleman1234 has provided some alternatives in his answer to this question.

How do we know the answer is "Not possible to the the full path in the kern.log segfault messages without recompiling the kernel":

We look in the kernel source code to find out how the message is produced and if there are any configuration options.

The files in question are part of the kernel source. You can download the entire kernel source as an rpm package (or other type of package) for whatever version of linux/debian you are running from a variety of places.

Specifically, the output that you are seeing is produced from whichever of the following files is for your architecture:

An example of the relevant function from one of the files(linux/arch/x86/mm/fault.c):

/*
 * Print out info about fatal segfaults, if the show_unhandled_signals
 * sysctl is set:
 */
static inline void
show_signal_msg(struct pt_regs *regs, unsigned long error_code,
        unsigned long address, struct task_struct *tsk)
{
    if (!unhandled_signal(tsk, SIGSEGV))
        return;

    if (!printk_ratelimit())
        return;

    printk("%s%s[%d]: segfault at %lx ip %p sp %p error %lx",
        task_pid_nr(tsk) > 1 ? KERN_INFO : KERN_EMERG,
        tsk->comm, task_pid_nr(tsk), address,
        (void *)regs->ip, (void *)regs->sp, error_code);

    print_vma_addr(KERN_CONT " in ", regs->ip);

    printk(KERN_CONT "\n");
}

From that we see that the variable passed to printout the process identifier is tsk->comm where struct task_struct *tsk and regs->ip where struct pt_regs *regs

Then from linux/include/linux/sched.h

struct task_struct {
    ...
    char comm[TASK_COMM_LEN]; /* executable name excluding path
                                 - access with [gs]et_task_comm (which lock
                                   it with task_lock())
                                 - initialized normally by setup_new_exec */

The comment makes it clear that the path for the executable is not stored in the structure.

For regs->ip where struct pt_regs *regs, it is defined in whichever of the following are appropriate for your architecture:

From there we see that struct pt_regs is defining registers for the architecture. ip is just: unsigned long ip;

Thus, we have to look at what print_vma_addr() does. It is defined in mm/memory.c

/*
 * Print the name of a VMA.
 */
void print_vma_addr(char *prefix, unsigned long ip)
{
    struct mm_struct *mm = current->mm;
    struct vm_area_struct *vma;

    /*
     * Do not print if we are in atomic
     * contexts (in exception stacks, etc.):
     */
    if (preempt_count())
        return;

    down_read(&mm->mmap_sem);
    vma = find_vma(mm, ip);
    if (vma && vma->vm_file) {
        struct file *f = vma->vm_file;
        char *buf = (char *)__get_free_page(GFP_KERNEL);
        if (buf) {
            char *p;

            p = d_path(&f->f_path, buf, PAGE_SIZE);
            if (IS_ERR(p))
                p = "?";
            printk("%s%s[%lx+%lx]", prefix, kbasename(p),
                    vma->vm_start,
                    vma->vm_end - vma->vm_start);
            free_page((unsigned long)buf);
        }
    }
    up_read(&mm->mmap_sem);
}

Which shows us that a path was available. We would need to check that it was the path, but looking a bit further in the code gives a hint that it might not matter. We need to see what kbasename() did with the path that is passed to it. kbasename() is defined in include/linux/string.h as:

/**
 * kbasename - return the last part of a pathname.
 *
 * @path: path to extract the filename from.
 */
static inline const char *kbasename(const char *path)
{
    const char *tail = strrchr(path, '/');
    return tail ? tail + 1 : path;
}

Which, even if the full path is available prior to it, chops off everything except for the last part of a pathname, leaving the filename.

Thus, no amount of runtime configuration options will permit printing out the full pathname of the file in the segment fault messages you are seeing.

NOTE: I've changed all of the links to kernel source to be to archives, rather than the original locations. Those links will get close to the code as it was at the time I wrote this, 2104-09. As should be no surprise, the code does evolve over time, so the code which is current when you're reading this may or may not be similar or perform in the way which is described here.

Answered By - Makyen

Answer Checked By - Pedro (WPSolving Volunteer)

This Answer collected from stackoverflow and tested by PythonFixing community admins, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Sunday, March 20, 2022

[SOLVED] Configure kern.log to give more info about a segfault

Issue

Solution

Popular Posts

Labels