Last modified: 2014-05-09 18:47:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T64098, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 62098 - LCStoreDB not working on postgres due to \0
LCStoreDB not working on postgres due to \0
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.23.0
All All
: Normal normal (vote)
: 1.23.0 release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: postgres
  Show dependency treegraph
 
Reported: 2014-03-01 09:17 UTC by db [inactive,noenotif]
Modified: 2014-05-09 18:47 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---
umherirrender_de.wp: Backport_to_Stable+


Attachments

Description db [inactive,noenotif] 2014-03-01 09:17:53 UTC
LCStoreDB has a problem under postgres.

The lc_key 'deps' contains objects which will be serialized and than there are \0 in the serialized string, but for postgres a \0 is end of input stream, this means the lc_value for deps is cut of at the first \0, which breaks unserialize when getting this value back.

The insert row is ([...] is a placeholder to make it shorter):
array (
  'lc_lang' => 'de',
  'lc_key' => 'deps',
  'lc_value' => 'a:9:{i:0;O:14:"FileDependency":2:{s:24:"' . "\0" . 'FileDependency' . "\0" . 'filename";s:110:[...];i:2;}}',
)

Gives:
INSERT /* LCStoreDB::set  */ INTO "l10n_cache" (lc_lang,lc_key,lc_value) VALUES ('de','deps','a:9:{i:0;O:14:"FileDependency":2:{s:24:"')

Reading on the internet, the only chance here is to use bytea, which can be done by using Database::decodeBlob and Database::encodeBlob. Than the \0 is changed to \000, but I didnot know, if oracle and sqlite still will work than.

Maybe there is another solution.
Comment 1 Aaron Schulz 2014-03-01 09:19:32 UTC
I ran into this problem last week too.
Comment 2 Jeff Janes 2014-05-01 22:00:59 UTC
I bisect this down to Change-Id I427c6de5a0a29b43cff755db0eb8a750db620173.

But that seems to be just a code beautification patch that should not change any behavior.  Why does that change expose this latent bug?
Comment 3 Aaron Schulz 2014-05-01 22:03:14 UTC
PHP seralizer uses \0 for private/protected fields. Since we stuff serialized PHP into the DB, this caused the problem.
Comment 4 Gerrit Notification Bot 2014-05-02 16:47:08 UTC
Change 131075 had a related patch set uploaded by Jjanes:
PostgreSQL: Make l10n_cache.lc_value binary

https://gerrit.wikimedia.org/r/131075
Comment 5 Jeff Janes 2014-05-02 16:50:30 UTC
(In reply to Aaron Schulz from comment #3)
> PHP seralizer uses \0 for private/protected fields. Since we stuff
> serialized PHP into the DB, this caused the problem.

Is there any way for the serializer to generate \0 without there being private/protected fields?  I wonder how likely it is that someone has already tried to store \0 even before I427c6de5a0a29b43cff755db0eb8a750db620173.
Comment 6 Gerrit Notification Bot 2014-05-05 22:51:20 UTC
Change 131075 merged by jenkins-bot:
PostgreSQL: Make l10n_cache.lc_value binary

https://gerrit.wikimedia.org/r/131075
Comment 7 Gerrit Notification Bot 2014-05-07 01:21:36 UTC
Change 131919 had a related patch set uploaded by Jjanes:
PostgreSQL: Make l10n_cache.lc_value binary

https://gerrit.wikimedia.org/r/131919
Comment 8 Gerrit Notification Bot 2014-05-09 13:57:09 UTC
Change 131919 merged by jenkins-bot:
PostgreSQL: Make l10n_cache.lc_value binary

https://gerrit.wikimedia.org/r/131919
Comment 9 Umherirrender 2014-05-09 18:47:34 UTC
patch set was successfully merged and backported

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links