narrowed down error to call_hook('post_system')

I am not sure why this is happening. If I run my code with xdebug enabled, apache crashes at line 559 of codeigniter.php. Since this is the codeigniter code and not in phpStorm not Apache, I figured that this might be the best place to try to resolve my issue. 
$EXT->call_hook('post_system');
I don't know what this is for but next the code goes to 

public function call_hook($which = '')
{
  if ( ! $this->enabled OR ! isset($this->hooks[$which]))
  {
     return FALSE;
  }
Which returns FALSE. 

And then directly to _shutdown_handler() below. Since $last_error is null, the _error_handler() does not get called and the system crashes. Is this the way this is supposed to work?

   function _shutdown_handler()
  {
     $last_error = error_get_last();
     if (isset($last_error) &&
        ($last_error['type'] & (E_ERROR | E_PARSE | E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_COMPILE_WARNING)))
     {
        _error_handler($last_error['type'], $last_error['message'], $last_error['file'], $last_error['line']);
     }
  }
}

proof that an old dog can learn new tricks

All is as it is supposed to be - except the crashing part. But the code and execution chain is as it should be.

call_hook() returns false because there is nothing associated with the "post_system" hook. (Unless you did define a hook for this point in which case it needs to be investigated.)

It is normal for CI to proceed with shutting down after $EXT->call_hook('post_system'); - the script CodeIgniter.php is done executing.

Why it is crashing is very strange but not related to CI. Possibly (most likely IMO) an xdebug issue or a phpStorm/xdebug bug.

Does everything run smoothly when you are not debugging?

Yes. When not in debug, no crash! I still have an issue with session cookies working sometimes and not other times. But I can't debug that problem if my debugger is crashing the entire system. On this crash issue, the phpStorm support people claim that it is a apache issue. I am wondering if it makes sense for me to update my version of xdebug? Or setup a Linux box to do development on? Or do I just wait a few days and see if it goes away again?

proof that an old dog can learn new tricks

Or do I just wait a few days and see if it goes away again?

LOL. Probably not going to be effective.

I'd suggest following all the steps at Troubleshooting PhpStorm debugging. The page may help you decide if upgrading xdebug is appropriate. Couldn't hurt to triple-check that Xdebug is configured properly before doing a upgrade too.

I don't use PhpStrorm so I can offer any better specific help. (I use Netbeans,)

In terms of a development environment I have had good success using Virtualbox to create LAMP stacks. Not a trivial task but not impossibly hard either. That approach has worked much better than WAMP or XAMPP setups because it's easy to create stacks that match the eventual live host's server, database, and PHP versions. Being able to create various server/db/php version combos with relative ease is very handy.

I also run a full Linux box too. It's my "bleeding edge" system that is kept updated to the latest and greatest stable releases. ("stable" is often an overly optimistic term.) Having a Linux box simplifies a lot of the process but there are some trade offs.

Back to your other problem.

I still have an issue with session cookies working sometimes and not other times.

Since sessions tend to work or they don't, (I've not seen them be intermittent) perhaps there is some problem with the session usage as opposed to how it is configured? What does the current implementation look like?

I will go through those troubleshooting /w phpstorm instructs carefully. Anyway, thhis is how I am setting the session data

 in controller A

//rnb added
$email = $this->input->post('email');
$this->session->set_userdata('userid', $email); //not be confused with userID which is built in
redirect('configure/index','refresh'); //success

I am basically creating a place in session called userid to store the email address before switching to controller B (called configure, it has a function called index().

In controller B I have a callback (I am using grocery crud)

function add_email($post_array){
   $post_array['email']=$this->session->userid;
   return $post_array;
}

Now when I look at the cookie artifacts being created from this session switcheroo, I see 9 different ones are created (I guess for different things). Only one of these 9 has the correct data including the email address. They all have the same timestamp, btw. Some are blank. Some only have the __ci_last_regenerate. My theory is that sometimes the wrong one is getting loaded in controller B. And that is what I was working on figuring out how CI knows which one to reload when the xdebug crash reappeared. 

 

proof that an old dog can learn new tricks

The session cookie won't contain the user data. Where that is stored depends on the driver you're using - 'files' in your case. You should look at the super global $_SESSION to determine what data the session class retrieved.

Or maybe when you say you're "looking at cookies" you don't mean that literally?

In the users controller I am using:
                   $email = $this->input->post('email');
                   $this->session->set_userdata('userid', $email);
This seems to create a element in the $_SESSION array called userid and contains the email address. This seems to work.
I then do  redirect('configure/index','refresh');
In the configure controller I have a callback
 function add_email($post_array){
       //$iRc=this->session->has_userdata('userid');
       //$current_user = $this->session->userid;
       $post_array['email']=$this->session->userid;
       return $post_array;
   }
The problem with using $_SESSION is that it has not been populated with any data from the old $_SESSION. It is blank.

proof that an old dog can learn new tricks

I thought we had your session config figured out and working. If you're up for it, session config can be doubled check by using the controller and view shown below.

Once you have created the files point your browser to http://yoursite.dev/test_sessions and see if it works. as advertised in the comments in the controller file.

File: /application/controllers/Test_sessions.php

PHP Code:

<?php
/**
 * This class is useful for testing the configuration of the CodeIgniter "session" library.
 * It works only for CodeIgniter versions > 3.0.0
 * 
 * If "session" is properly configured then each click of the button will toggle the "status" of the user
 * as indicated by the text of the button. It changes from "Log In" to "Log Out" on each press.
 * No matter the "status", a reload of the page should not change the "status".
 * IOW, the button text won't change. 
 *
 * You should be able to browse away from this page and then back to it without the "status" changing.
 * 
 */
defined('BASEPATH') OR exit('No direct script access allowed');

class Test_sessions extends CI_Controller
{
    /**
     * This constructor can be deleted if library 'session' AND helper 'form' are autoloaded.
     */
    function __construct()
    {
        parent::__construct();
        $this->load->library('session');
        $this->load->helper('form');
    }

    public function index()
    {
        $this->load->view('test_sessions_view');
    }

    public function process_submit()
    {
        //we literally check the button submit value to decide what to do
        if ($this->input->post('submit') === "Log In")
        {
            $_SESSION['status'] = "Log In";
        }
        else
        {
            session_destroy();
        }
        redirect('test_sessions', 'location');
    }
} 


file: /application/views/test_sessions_view.php

PHP Code:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <title>Session Testing</title>        
    </head>
    <body>
        <?php
        echo date("F j, Y, g:i:s a")."<br>"; //so you can tell the page actually does refresh/reload
        echo form_open('test_sessions/process_submit');
        
        // button label depends on if 'status' is found in $_SESSION
        $btn_text = $this->session->status ? "Log Out" : "Log In";
        echo form_submit('submit', $btn_text);
        echo form_close();
        var_dump($this->session->userdata()); //Show all user data.
        ?>
    </body>
</html> 


I find this pair of files helpful because they focus on session class usage without much in the way of other logic to complicate the situation.

Thanks Dave. I created the controller: test_sessions.php and also the view file: test_sessions_view.php. I tried running by typing in http://localhost/sub_crud/test_sessions.php and I get Object not Found!

Is there anyplace else I need to change?

my routes.ini has

$route['default_controller'] = 'users/login';
$route['404_override'] = '';
$route['translate_uri_dashes'] = FALSE;
$route['registration'] = 'registration';
$route['login'] = 'login';

proof that an old dog can learn new tricks

Uppercase first letter on the controller file name i.e Test_sessions.php ?

Those last two routes are not needed as far as I can see.

Wait a second... I just noticed the URL you used.
You're putting controllers in subdirectories?
That's a practice that i find more trouble that it is worth. But that's just me.

For the sake of this experiment move the controller to the /applications/controllers/ folder.
Then use the URL http://localhost/test_sessions (no need for the file extension)