Error "Failed to start the session: already started by PHP"

This patch fixes a problem we are having locally, with a "Failed to start the session: already started by PHP" error. Thank you!

I don't understand the internals enough to say what module or code we have that is causing the conflict.

Are the test failures here false alarms?

Similar to @brockfanning; our local instances use local login -- simplesamlphp is only active "cloud" instances. The error started popping up when a recent composer update moved us to 1.17.2. This patch fixes it. Thanks!

Can you check if #3050273: Require SimpleSAMLphp ^1.17.2 and use namespaced class names fixes the problem as well? Then I'll close this as a duplicate, although I already suggested in #2915568: Installing the module causes exception and Drupal whitescreen to switch to a lazy load implementation similar to what was proposed here.

Can't speak to the OP's use case, but the patch at #3050273: Require SimpleSAMLphp ^1.17.2 and use namespaced class names doesn't resolve this problem for us. The "Failed to start the session: already started by PHP" error returns for local login attempts.

RuntimeException: Failed to start the session: already started by PHP. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 137 of /var/www/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
Drupal\Core\Session\SessionManager->startNow() (Line: 240)
Drupal\Core\Session\SessionManager->regenerate(, NULL) (Line: 188)
Symfony\Component\HttpFoundation\Session\Session->migrate() (Line: 564)
user_login_finalize(Object) (Line: 145)
Drupal\user\Form\UserLoginForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 589)
Drupal\Core\Form\FormBuilder->processForm('user_login_form', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('user_login_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Ah I see, I thought it's the configuration stuff or a warning message or so, but I got it now.

Then lets do the lazy initalization here, but I'd prefer to just change $this->instance to $this->getInstance() and then initialize inside it.

#2915568: Installing the module causes exception and Drupal whitescreen does include the same kind of lazy loading that should fix this.

Berdir, was that meant to be posted in another issue? The link is to here I think.

Fixed the link, sorry.

This patch worked well for me! In case anyone needs it, I'm also attaching a patch that should apply cleanly to the 3.0 release of the module as well.

UPDATE: This patch actually does not work for me any longer, but checking out the full 3.x-dev code resolves this issue completely.

I'm trying the latest 3.x-dev code now, without any patches, and the problem appears to be gone. @afireintheattic could you confirm?

@brockfanning The patch I posted above that is rolled against the 3.0 release actually does not work; however, I did checkout the 3.x-dev code and can confirm that it does indeed resolve the issue for me. This is a bit of a blocker for use, so hopefully this gets released soon! :D

I was waiting on some confirmations that this is indeed the case as I didn't have a chance yet to test it myself. Closing as a duplicate then.

Here we go: https://www.drupal.org/project/simplesamlphp_auth/releases/8.x-3.1