We don't support PHP patched with 3rd party patches like Suhosin, what is the results without, and what does valgrind give you? Should show if there is a real leak

I forgot to include, did you try to disable the Zend allocator (USE_ZEND_ALLOC)?

Now I was able to test this case with a fresh new setup, now really v5.3.2 (the previous was 5.2.9, but I opend the ticket as 5.3.2).

The problem without Suhosin or any other extension doesn't appear, so the first question is solved.
But I observed something: the header of the HTTP response contains a lot of Set-Cookie line, one for each session_start() call.
I don't think it's the right way it should work.

That is expected. You might have sessions with different session names and keeping a list of them is a source of more trouble than simply sending them out in the correct order and letting the browser decide which to keep. Especially as usually no application doe multiple session_start) calls.

In my case I start a database synchronization from a website, send the job to the background, and show the actual result to the user.
e.g.:

if (isset($_POST["user_clicked_on_the_synch_button"]))
{
  header("Location: ?result_page");
  header("Content-length: 0");
  header("Connection: close");
  session_write_close();
  usleep(100);

  // at this point the browser goes to the result page, and we can start the synchronization process in the background

  synch();

  // this event handler is called after every synchronized product
  function onSynchEvent()
  {
    // here i need to save the actual state of the synch process
    session_start();
    $_SESSION["blah"]++;
    session_write_close();
  }
}

On the result page I can check this session variable with periodic ajax requests. The session has to be closed due to the file lock.

This is why I have to call session start/close multiple times.
Since the browser is already detached, it throws the "cannot start session, headers already sent" errors, but even then the data is stored in session.