PDO Exception after upgrading from Drupal 6.19 to Drupal 7 RC1

Confirmed, http://api.drupal.org/api/drupal/includes--session.inc/function/drupal_s... generates a 98 character long session id and the sid column in the accesslog is 64 only vs sid in session which is 128

doh. subscribing

Patch.

Here's a nearly identical patch with tests.

Quick job, thanks.

The tests pass on their own without the .install hunk. Looking at my {sessions} table, I'm seeing a 43-character sid. How is it possible to get a 98-character one?

Here's a test I did to see what this actually does:

session_id(drupal_hash_base64(uniqid(mt_rand(), TRUE) . drupal_random_bytes(55)));

$mt_rand = mt_rand();
$uniqid = uniqid($mt_rand, TRUE);
$random_bytes = drupal_random_bytes(55);
$hash_base64 = drupal_hash_base64($uniqid . $random_bytes);

var_dump(compact('mt_rand', 'uniqid', 'random_bytes', 'hash_base64'));

uname -a
Linux foo.bar 2.6.32.9-rscloud #6 SMP Thu Mar 11 14:32:05 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

array(4) {
  ["mt_rand"]=>
  int(308225643)
  ["uniqid"]=>
  string(32) "3082256434cfe72ef0da582.86798437"
  ["random_bytes"]=>
  string(55) "(breaks d.o comments)"
  ["hash_base64"]=>
  string(43) "wlSUA2uXMy6CooTP4PnXyVnruJHEfGBT2-VGLf8SZ5k"
}

uname -a
Darwin foo.bar 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov  5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386

array(4) {
  ["mt_rand"]=>
  int(1521357914)
  ["uniqid"]=>
  string(33) "15213579144cfe75959ceb75.91622075"
  ["random_bytes"]=>
  string(55) "(breaks d.o comments)"
  ["hash_base64"]=>
  string(43) "6AFcqoK2jt0jSDBTeUi7U3TBueeICXc9uo-4uScfueE"
}

In CentOS 5.5 64bit and Mac OS X i386, I get 43-character session IDs consistently. Can someone who can reproduce this bug run the above script and show a session ID longer than 64 characters?

Debug script attached.

debian:/var/www/d7# php test.php
array(4) {
  ["mt_rand"]=>
  int(2103427440)
  ["uniqid"]=>
  string(33) "21034274404cfe845342e381.08635206"
  ["random_bytes"]=>
  string(55) "}▒▒#2M[▒▒▒▒▒oSF▒E▒:7▒▒▒▒▒W*
ה<O▒<m▒q▒▒▒h1▒:▒▒G"
  ["hash_base64"]=>
  string(43) "hSMjoeWkgUuLJM4hyT4_DpiumjFo05GgYTfBjse0SCg"
}
debian:/var/www/d7# uname -a
Linux debian 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC 2010 i686 GNU/Linux
debian:/var/www/d7# cat /etc/debian_version
5.0.7

EDIT http://php.net/base64_encode Base64-encoded data takes about 33% more space than the original data.

While the bug is real -- ie statistics need the same data length as session table -- it's not critical as I can confirm carlos' work and confirm i am an idiot 'cos i wrote the wrong test scripts -- i moved a ) to the wrong place :( we need the original reporter to tell us more about the OS and the database used 'cos if you look better at the query posted, that's 43 characters right there. And sid was 64 in D6 already.

The tests need work since they happily pass without any fix.

OK i reviewed CVS history and -- this is why we did not put update functions in modules before. See, some time in the ancient past we upped the sid in accesslog to 64 but for whatever demented reason we put that update in statistics.install. And so whoever upped some time in the ancient past from one ancient Drupal to Drupal 5 with statistics disabled have sid length set to 32...

I reviewed a Drupal 5 checkout i had lying around and only blogapi, comment, statistics and of course system had updates. As far as I can see, the comment one does not change schema (and disabling comment if you have comments on the site is superb unlikely anyways), blogapi has a Drupal 6 counterpart and statistics is fixed up here. Drupal 6 already was running disabled modules updates as broken it was but it was doing the best it could.

I second the RTBC, this is a case of an outdated schema due to a deleted update function. Unfortunately in the old days, disabled modules didn't participate in updates. But now they do, so this new update should fix the issue.

Also: the new tests aren't totally relevant to this issue, but the extra coverage can't hurt.

Ok, Committed to HEAD. Thanks!