[Galaxy S 4 i9505 Original Android Development] NZgeek:
Depending on how the phone reboots, you may or may not be able to capture log information about the reboot. If you see the full boot sequence, including the black and white "Samsung Galaxy S4" logo, the kernel has restarted and the log info will be wiped. If you skip that screen and go straight to the boot animation, there's a chance you can capture a log.

Preparation

In order to capture the log info, you'll need to install an app called CatLog. This is a GUI for the command-line logcat app, which displays the system log. The logcat app needs to be run as root, so make sure you launch CatLog and grant it root access. Log entries should start showing up after a few seconds.

When you've got the app installed, I would highly recommend putting a shortcut to it on one of your home screens. Speed is the key to capturing the log info that says why the reboot happened. The log can only hold a certain number of entries, and old items will be removed as needed to make room for new ones. The home screen icon helps you launch the app as quickly as possible.

When a reboot happens

As soon as you're able to, unlock your phone and bring up CatLog. Wait until the first log entries show up, then hit your menu button, then Save (middle icon, top row). Hit OK to accept the default file name.

With any luck you've now captured the cause of the reboot.

Checking the log

When you've saved the log, you'll want to check if it contains information about the reboot. The log file should automatically open after you save it, but you can also open older logs from within CatLog.

When the phone does the shortened reboot cycle, it almost always means that the Android runtime environment has rebooted. By looking at the log entries for the runtime, you should be able to see the target information is there.

With the log open, tap into the filter box and start typing AndroidRuntime. An autocomplete entry should show after a few letters. Tap it to display just the runtime log entries.

The information you're liking for is most likely near the top of the file, so go to the top and start making your way down. The first thing you're looking for is a block of entries with a red error icon down the left. If you find one of these blocks, check the text to see if any of them start with "at android.something" or "at java.something". If so, you've found a call stack for an unhandled exception. This is the best information that the log can provide. Post all of the red entries here and the devs have a pretty good chance of identifying the issue.

If you don't find the red entries, you'll need to carefully look through the entries with blue icons to see if any say "Shutting down VM". If you find it, have a look just above it to see if there appears to be anything relevant. If not, take a more of the timestamp immediately above the text, then clear the filter. Use the timestamp to find the log message again, then check above it for anything that looks relevant. If you do find anything, post it here.

If neither of these options turn up anything, you may need to upload the whole file somewhere for others to check through.

Hopefully this helps. I'm sorry that it's a huge wall of text, but I have used these steps to help successfully track down an issue with another ROM.