How to analyze a kernel panic messages from crash to diagnose problem?

Question

I am developing a new iPad application . I end up with multiple master as well as multiple detail.

I searched the stackoverflow and found the same article : iOS - UISplitViewController with storyboard - multiple master views and multiple detail views

Since I am a new user, I can not comment on the same article.

My question is where should I put the UISplitViewController in storyboard?

As per the above article , "(1)Navigation Controller -> (2) table view of 6 menu options -> (3) Each cell in the table pushes a different table view controller onto the navigation stack."

should I put split view controller here before (3) or it will go somewhere else?

I am new to ios development, any help will be appreciated.

Solution

Quick Answer:

This looks related to kernel bug #13998 (see below for how I came to this conclusion), which has not been reproduced in later kernel versions. If this is the case, upgrading to a newer kernel (or a newer version of CentOS, same difference), should resolve the issue which is related to the fscache module.

Clues to fscache being the problem:

PANIC: "BUG: unable to handle kernel NULL pointer dereference at 000000000000002"

Means the kernel tried to load a memory address that made no sense.

COMMAND: "kslowd002"

This is the command the kernel was trying to run when it panicked. This does not necessarily mean this was the command that caused the crash, but it's a good place to start. What is kslowd? Read up on it here.

In the backtrace:

#9 [ffff880100003dd8] fscache_object_slow_work_execute at ffffffffa0460e9f [fscache]

Is the last procedure that runs before:

[exception RIP: unknown or invalid address]

This is the NULL pointer that the kernel couldn't dereference, in other words the place the kernel tried to look in memory but couldn't because it doesn't exist. This is a known bug with fscache that was, apparently, resolved in later kernel versions.

Here is a CentOS-6 specific bug report (#0007782) for the same issue that was not resolved. The recommendation from CentOS is also to make sure the kernel is the newest available version, which may in your case required an upgrade to the next stable major release of CentOS.

For more information on reading these crash dumps, I highly recommend this tutorial: http://www.dedoimedo.com/computers/crash-analyze.html

Comments

[am176]

Thanks for your reply . I will implement it and let you know how does it go.

[PolkaRon]

Hello, thank you for your input. I am running kernel release 2.6.32-642.1.1.el6.x86_64 which is the latest version available for CentOS 6.8 so I'm unable to update the kernel furthermore. Since it's already the latest version, I don't think it's the issue unless you believe updating to CentOS 7 will fix it. I'll read up on the crashdump link to see if I can pull any information from my server's dump file. Thanks again.

[Josh Benson]

The bug was reported on kernel 2.6.38.8. CentOS 7 uses the 3.x series of kernels, so upgrading to 7 would give you a newer kernel version (for comparison, the latest kernel release "in the wild" is 4.x). I see that CentOS was releasing patches for your kernel as recently as May of this year, so it's odd a patchfix for this issue hasn't been pushed down given this bug was reported in 2009. Short of waiting for a response to your bug report, unless there are any compelling reasons not to do so I would recommend an upgrade as generally advisable anyway.

[Josh Benson]

I edited my answer to provide a link to a CentOS bug report for this issue that was not resolved (because the original reporter stopped responding), but where a kernel/system upgrade was recommended to resolve it.

[PolkaRon]

Got it. I will be saving an upgrade to CentOS7 as a last resort.