Magento page freeze/blank after account creation - magento

Question

RE: EE v1.10.1.1
Hello,
Recently I've discovered that registration process page freezes after a user submits the form to create an account. It dies on '/customer/account/createpost/'.
Seems to die on this line in the /app/code/core/Mage/Customer/controllers/AccountController.php around line #325 ($session->setCustomerAsLoggedIn($customer);).
It seems to choke on an invalid/empty session when going to set user as logged in. Only after refreshing the frozen page wlll it logs/displays an error. I haven't found any other errors/warnings/messages that are logged... in any of the logs (to include server logs):
a:5:{i:0;s:62:"Mage registry key "_singleton/customer/session" already exists";i:1;s:1247:"#0 /server_path/html/app/Mage.php(192): Mage::throwException('Mage registry k...')
#1 /server_path/html/app/Mage.php(446): Mage::register('_singleton/cust...', Object(Mage_Customer_Model_Session))
#2 /server_path/html/app/code/core/Mage/Customer/controllers/AccountController.php(50): Mage::getSingleton('customer/sessio...')
#3 /server_path/html/app/code/core/Mage/Customer/controllers/AccountController.php(75): Mage_Customer_AccountController->_getSession()
#4 /server_path/html/app/code/core/Mage/Core/Controller/Varien/Action.php(409): Mage_Customer_AccountController->preDispatch()
#5 /server_path/html/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(253): Mage_Core_Controller_Varien_Action->dispatch('create')
#6 /server_path/html/app/code/core/Mage/Core/Controller/Varien/Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#7 /server_path/html/app/code/core/Mage/Core/Model/App.php(340): Mage_Core_Controller_Varien_Front->dispatch()
#8 /server_path/html/app/Mage.php(627): Mage_Core_Model_App->run(Array)
#9 /server_path/html/index.php(95): Mage::run('', 'store')
#10 {main}";s:3:"url";s:25:"/customer/account/create/";s:11:"script_name";s:10:"/index.php";s:4:"skin";s:2:"sg";}
The next line (#326) sends the welcome email. If line #325 is commented out then the email is still sent and, if this is done, the very first attempt to login to their account chokes on '/customer/account/loginPost/' on line #137:
$session->login($login['username'], $login['password']);
Refreshing the page one time displays the dashboard.
Either way the account appears to be created properly and account functionality is normal afterwards, no other login issues.
There have been a few recent changes, but none of them should have anything to do with the customer and/or customer/sessions... at least not that I'm aware of.
By chance does anyone have an idea on any common potential magento pitfalls in code... where I could have done something indirectly in another script/mod that would cause something like this?
I've been going over this way longer than I should and feel I've circled back to the starting point without any leads/success. I kinda feel like I'm missing/overlooking something obvious. Any input, thoughts, suggestions or ideas are appreciated.
Thanks.
Respectfully,
JamesD
[b]Note:[/b] The last time I personally checked this functionality was a month or two ago and it wasn't doing this. I have made/added a few custom mods since, but again they should not be 'directly' connected to customers and/or customer sessions.
Also, over a year ago we did add some additions to the 'customer_login' and 'customer_before_save' events, but there haven't been any issues with them in the past, so I wouldn't think either of these would be the cause.. The only other change would be a Magento upgrade from EE 1.9 to 1.10.
Empty session example....
Here's what the session looks like when the page chokes:
Mage_Customer_Model_Session Object
(
[_customer:protected] =>
[_isCustomerIdChecked:protected] =>
[_skipSessionIdFlag:protected] =>
[_data:protected] => Array
(
[_session_validator_data] => Array
(
[remote_addr] => 155.77.22.255
[http_via] =>
[http_x_forwarded_for] =>
[http_user_agent] => Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11
)
[session_hosts] => Array
(
[www.slimgenics.com] => 1
)
[id] =>
[messages] => Mage_Core_Model_Message_Collection Object
(
[_messages:protected] => Array
(
)
[_lastAddedMessage:protected] => Mage_Core_Model_Message_Success Object
(
[_type:protected] => success
[_code:protected] => Thank you for registering.
[_class:protected] =>
[_method:protected] =>
[_identifier:protected] =>
[_isSticky:protected] =>
)
)
[before_auth_url] => https://www.domain.com/customer/account/index/
[no_referer] => 1
)
[_hasDataChanges:protected] => 1
[_origData:protected] =>
[_idFieldName:protected] =>
[_isDeleted:protected] =>

Answer 1

The error you describe should raise here (magento CE 1.7.0.2 for reference):
// app/Mage.php:472
$registryKey = '_singleton/'.$modelClass;
if (!self::registry($registryKey)) {
self::register($registryKey, self::getModel($modelClass, $arguments));
}
So it is checked immediatly before the registration wether this key exists. I don't think, the EE code does something else. So the question you have to answer is: Why is !self::registry($registryKey) false?
You have luck I dug deeper. I think the creation of the Session-Object fails and returns false. This means the check for the key is true, but the check in Mage::register() failse, because it checks with isset():
// app/Mage.php:216
public static function register($key, $value, $graceful = false)
{
if (isset(self::$_registry[$key])) {
if ($graceful) {
return;
}
self::throwException('Mage registry key "'.$key.'" already exists');
// [...]
The question is: why fails the creation of the session object.

Answer 2

The problem has been solved.
The problem stemmed from a change in a file that I was unaware of.
That change apparently caused a loop (where it was dying) throwing a 'Cannot redeclare' message. Caused from a 'require' statement in a file that was being called multiple times.
The only way I found this out was from a custom API. I used it to test the account creation functionality and fortunately the Soap handler was able to throw the error and log it within the Magento error.log (which it never did before). That 'redeclare' error message was in there and led me to the file that had been changed.
Thanks to all of you for your input.