あらためてコード見なおしたら clear(key) となっていたので書き間違いな気がします。とりあえず removeItem(key) に修正してしばらく様子を見てみます。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

デバッガーのスクリーンショットを見ると、flash(flushではない)の中のclear()が、self.storage.clear(self.key) となっていますね。
気がつかなかった(^^;

self==thisで、self.keyは、self.itemが空では無い時に行っている、self.storage.setItem(self.key,JSON.stringify(self.item))　で使うキーです。
import(storageKey,itemKeys) の中では、var item=JSON.parse(this.storage.getItem(storageKey)を行い、
itemKeysで指定されたkeyについて、JSON.parseで得たitemの中のデータを、this.item[key]に入れています。
多分、このコードのlocalStorageは自前のオブジェクトで、this.storageに本物のlocalStorage(window.localStorage)、this.keyにJSONデータのキー、.this.itemに実行中に使う各種設定データを入れているのでしょう。
this.flash()は、次回のためにthis.itemの内容を、JSONデータとして、window.localStorageにthis.keyをキーとして保存するコード、に見えます。
だとすると、this.flash()で、self.itemが空の時に行っているself.storage.clear(self.key)は、
保存するデータが無いので、window.localStorageのthis.keyをキーとするJSONデータを消す、ということなのでしょう。

そうであるならば、ここでのclear()の使用は、多分removeItem()との混同でしょう。
self.itemが空の状態で呼ばれたら全部の行を消し、self.itemが空の状態ではないならばJSONデータを保存、というコードの仕様も有りですけど、それならば、self.storage.clear(self.key)であってはならない。
self.item(this.item)が空の時はself.storage.setItem(self.key,JSON.stringify( {} )でよくて、こっちを使っていれば、clear()の誤用も起こり得ないし、バグにも遭遇しないはず...

他でもclear(key)が見られるのならば、clear()の多用ではなく、clear()の誤用になります。
もし、clear()の誤用があり、上記のself.itemのJSONデータ以外についてもsetItem()/removeItem()を行っていて、その頻度が高ければ、
clear()とsetItem()/removeItem()の間の競合、clear()とclear()の間の競合、が起こり得て、
おっつけ、clear()でROLLBACKを出した時にSQLITE_ABORT_ROLLBACKが返ることも発生するでしょう。
そうなれば、ROLLBACKを再発行しない問題が起こり、その時には結構高い確率でリリースされないロックが発生すると思います。

のその後の報告です。結局、エラーには関係ありませんでした。履歴の消去とかの操作をしないと実行しない箇所だったので。
それで別トピックに触発されて timestamp,mozStorage:5 のNSPRログを出してしばらく運用していたのですが、1回だけエラー発生時のログを取ることができました。
発生時点のログは以下のようなものです（データ内容は削っています）。

ちなみに、削った value はスレッドの閲覧のたびに更新される履歴情報（多めに１００件）や設定値などが格納されていてサイズが16KB近くあります。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

既にロックアウトが発生していて、たまたま履歴の消去とかの操作をしたのであのコードを通り、SQLITE_BUSYが引っかかった、という感じですね。

mozStorage:5 というのがありましたか。

'1.0.0.721.:http:8823' は、おそらくscopeそのままで、URLとしては、http://127.0.0.1:8823、
loopback？
for 'ROLLBACK' ときて、database is locked、とくると、ROLLBACKにSQLITE_BUSY、が怪しいですね。

key='skin.gray2x',でInsertかReplace(localStorageだから、setItem)ですが、これは、件のスキンのものですか？
そうならば、JvaScriptのsetItemなどのコールのところのcatch(e)で引っ掛けらる？
mozStorage:5 のログとあわせれば、2013/9から放置しているバグによって問題が実際に起こった、という証拠を叩き突きつけられる(^^)

[追記]
Bug 1062823 と Bug 951934 に、このログの件を報告しておきました。

http://mxr.mozilla.org/comm-central/source/mozilla/storage/src/mozStorageStatement.cpp#638
Statement::ExecuteStep error: のログは、
638 int srv = mDBConnection->stepStatement(mNativeConnection, mDBStatement);
でエラーが返った時に書かれます。
[/追記おわり]

はいそうです。chaikaは 127.0.0.1:8823 のローカルプロキシで動作しますのでgrayスキンもそのスコープでストレージに保存します。


おおう、行動が速いですね。エラーの箇所についてはこちらも初めてソースをダウンロードして検索して確認しました。
ログをざっと見て気づいたことを書いておきます。

• 127.0.0.1:8823 のスコープで webappsstore2 にアクセスしてるのは grayスキンが履歴更新しているのみです。

• アプリタブで twitterとYouTubeを開いているのですが、https://twitter.com と https://www.youtube.com が高頻度でwebappsstore2にアクセスし続けている。twitterが時々ユーザープロファイルのでかいデータを更新しているのにちょっとびっくりしました。

なにか参考になれば幸いです。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

[quote="EarlgreyTea"]ログをざっと見て気づいたことを書いておきます。

• 127.0.0.1:8823 のスコープで webappsstore2 にアクセスしてるのは grayスキンが履歴更新しているのみです。
• アプリタブで twitterとYouTubeを開いているのですが、https://twitter.com と https://www.youtube.com が高頻度でwebappsstore2にアクセスし続けている。
  twitterが時々ユーザープロファイルのでかいデータを更新している

grayスキンの中だけで頻繁に競合が発生するとは思えないから、
複数の、異なるkeyのsetItem()で、行の範囲の更新ロックの競合が起こる
⇒ grayスキンが勝ち、他にはSQLITE_BUSY
⇒ grayスキンが、行の書き込みロックをとる
⇒ SQLITE_BUSYが返ったほうで、grayスキンの処理が完了する前に、ROLLBACK
⇒ ROLLBACKが勝って、他のリクエストのROLLBACKが処理される
⇒ grayスキンにSQLITE_ABORTが返る。おそらく、行の範囲の更新ロックはフリーされる。
⇒ SQLITE_ABORTで何もしなくて、ROLLBACKを出さないから、行の書き込みロックは保持されたまま
⇒ grayスキンで同じ行の更新が入ると、SQLITE_BUSY ⇒ ROLLBACK ⇒ SQLITE_BUSY
⇒ あの、Rollback()によるROLLBACKの場合は、無限ループ
⇒ Read(getItem)はできるから、更新したはずの行が更新されていない、という現象が起こる
という感じかな？

ちょっと、訂正です。

sqlite3_traceのログが書かれるタイミングを勘違いしていました。
setItem('skin.gray2x',...) ⇒ INSERT OR REPLACEの、sqlite3_trace ログ ⇒ INSERT OR REPLACE の実行 ⇒ SQLITE_BUSY ⇒ Statement::ExecuteStep error: database is locked のログ ⇒ ROLLBACK がだされて、ROLLBACKのsqlite3_trace ログ
だと思います。

SQL文の実行 ⇒ エラーがあると、Statement::ExecuteStep error:のログ ⇒ 終了後に、sqlite3_trace ログ
だと、setItem('skin.gray2x',...)によるINSERT OR REPLACEは成功しているわけで、そもそも、ROLLBACKがでること自体がおかしい。

上記のログは、ROLLBACKの後に、key='skin.gray2x'に対してもう一度INSERT OR REPLACEが実行されていれば、
単に、SQLITE_BUSYが一度返った、ということになると思います。

でも、clear()以外は一行の更新しかしないlocalStorageで、
localStorage.clear()を scope="http://www.youtube.com" で頻繁にだすはずがなく、99.99%の更新はsetItemかremoveItemしか考えられないlocalStorageで、
同じscopeの同じkeyの行を複数のタスクが同時に更新する、ということはあまり考えられないlocalStorageであっても、
SQLITE_BUSYが返った後にROLLBACKがだされることが実際に起こる、という証拠を得られたのは、大収穫です。
ROLLBACKを出すコードがあったって、そのコードがlocalStorageのアクセスで実際に呼ばれて実際にROLLBACKがでるかどうかなんて、プログラムを書いた本人だって、コードを見ただけで簡単にわかるはずがない。
setItem()からROLLBACKコールに到る長い道のりの、自分が知らないどこかにif(flag)break;があって、知らない人がいつの間にかflag=trueをセットしていた、なんてなことは、良くある話。
やっぱり、「ROLLBACKが出ていた」という、直接証拠が一番(^^)

折角 mozStorage:5 を教えてもらったので、ちょっと見てみました。

• cookies.sqlite の moz_cookies
  　Transactionのような概念を持たず、全て単独のSQL文の実行
• places.sqlite の ブックマーク系(moz_bookmarks, moz_places, moz_favicon) :
  　BEGIN IMMEDIATE　＋　0個以上のSQL文　＋　COMMIT TRANSACTION
• places.sqlite の ブックマーク系以外
  　BEGIN DEFERRED　＋　1個以上のSQL文　＋　COMMIT TRANSACTION
• webappsstore2
  　BEGIN DEFERRED　＋　1個以上のSQL文　＋　COMMIT TRANSACTION

moz_cookiesは、1 Table のみ、一回に一行しか更新しない、各行は完全に独立、
ブックマーク系は、Table は3つだけれど、一回に各Tableの一行のみしか更新しない、
ブックマーク系以外は、複数のTableの複数の行の同時更新があり得る、
webappsstore2は、Tableは1つだけれど、複数の行の同時更新があり得る、
といったような違いによって、mozStorageの利用のしかたが異なるようです。

で、BEGIN DEFERRED/BEGIN IMMEDIATEだと、COMMITするか、COMMITできなければROLLBACK。
のはずが、COMMITできない・できていないのに、ROLLBACKをださないことがある、と。
[ちょっと訂正]
ROLLBACKをださない、ではなかった。
setItem()によるInsert/Replceと他のリクエストで競合が起こった時に、
自分が勝つと、競合相手にはSQLITE_BUSYが返るので、競合相手がROLLBACKをだし、
今度は、その競合相手がだしたROLLBACKに自分のInsert/Replceが負けて、その結果SQLITE_ABORTが返ってきて、COMMITできないからROLLBACKをだすのだけれど、
それも競合相手がだしたROLLBACKに負けると、今度はROLLBACKにSQLITE_ABORT_ROLLBACKが返ってきて、
その時に、もう一度ROLLBACKをださないから、結局、ROLLBACKをだしていないのと同じになり、
最初にSQLITE_ABORTが返った時点で行のロックがとれていると、ロックがリリースされなくなる。
競争に勝った方が、負けた方のROLLBACKによって躓いて大逆転がおこり、あげくのはてに、踏みつけられてボロボロになる(^^)
[/ちょっと訂正のおわり]


参考までに。

EarlgreyTea さんは、Windowsユーザーでしたね。
それならば、DebugViewにmozStorge:5のログを書かせておき、普段はDebugViewのCaptureを止めておき、
できるだけ多くのlocalStorage.setItem()/removeItem()/clear()をtry/catchに入れておき、
localStorage.clear()などのcatch(e)でエクセプションを検出した時に、DebugViewのCaptureを開始して、
Custom Buttonsというアドオンで追加した自前のツールバーボタンで、そこで使われたscopeに対して、
を行うと、もう少し詳しい状況がわかると思います。

DebugView : https://technet.microsoft.com/en-us/library/bb896647.aspx

scopeを選択する方法。

なるべく情報提供に協力したいと思いますが、ひとまず検討させてください。再現可能なミニマム環境にもう一度トライしてみたいですね。前やった時は拡張機能しか頭になかったので。新規プロファイルにツイッター、YouTube、FoxAge2ch、chaika+grayで行けそうな気がしてます。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

chaika+grayを使っていれば、try/catchを入れているし、問題が起これば気がつくし、もう、しゃかりきになって再現させなくても良さそうな気が。
localStorageのsetItem/removeItemという、一つの行しか更新しないトランザクションの間の話ですから、同じscope内の競合、同じscope+keyの間の競合、ではなくて、別のscopeの間の行の範囲の更新のためのロックの競合、という気がします。
ならば、いくつかのツールバーボタンで、一つあるいはいくつかのscopeについて、setTimeoutでsetItem()やremoveItem()を繰り返しだしてたまにはclear()をだして、try/catchでエラーを検出しておけば、いずれどここかで、GoogleとかYahoo!とかTwitterとかのスーパーヘビーユーザーと競合して、なんらかのデータがとれそうに思います。
向こうが先に競合に勝つと、負けたこちらのROLLBACKで向こうがこけて、Google地図やYahoo!地図の一部が欠けるといった現象を引きおこせるかもしれません(^^)

これ自体は、提示したスクリプトでわかるとおり、非常に簡単。
あれは、WebサイトのHTML用のwindowコンテキストを作って、window.locakStorageというオブジェクトを作るコードをパクっただけ。
Custom Buttonsで作ったボタンは、普通にツールバーボタンですから、そこに貼り付けたスクリプトは、普通にツールバーボタンのスクリプトとして動くから、何でもできます。

WADAさんに教えていただいたCustom ButtonsとDebugViewを準備し、通常使用していてエラー発生した際のNPSRログ（常時キャプチャ＆ログ書き出し）を取りました。
前回の事例ではchaikaのgrayスキンが履歴を更新する際のエラーでしたが、今回は https://twitter.com:443 スコープで先にエラーになった事例です。
どうやら、[2711140]の Initialized statement ... Finalizing statement の間に[2043b8e0]が割り込んだ形になってるようです。

この状態のまま、Custom Buttonsのボタンからスクリプトを走らせてテストを行いました。以下がそのスクリプトです。

一部省略してますが、配列siteには事前にFirebugのFireStorage Plus!パネルで調べた全サイトをセットしておきます。
ブラウザコンソールを開いておくと正常時は、
となるところ、で終了しました。getLocalStorageForPrincipal() の時点でNS_ERROR_STORAGE_BUSYが発生しているようです。

一方、NSPRログは正常時は、
といった具合に出力されますが、例外が出てスクリプト終了しているのでログには残っていません。
ちなみにこのエラーはGoogleスプレッドシートをいくつか開いておいたタブグループをカレントに切り替えた途端に発生しました。

【余談】
ブラウザーコンソールを開いていると拡張機能やWEBアプリが頻繁に未定義変数参照のTypeErrorを吐き続けるし、何より新規プロファイルであっても起動時に必ず
を出してくるのが気になります。
ちょっとググってみたら、Bug 586610 というのが見つかったけど初出が2010-08-12。
悪さはしないけど正常時のログはスッキリしてて欲しいなと思ったり。

_________________
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

ここで言う「エラー」は、
00182974 14:59:19.133 [4424] 2480[2043b8e0]: sqlite3_trace on 2050d640 for 'BEGIN DEFERRED'
00182975 14:59:19.133 [4424] 2480[2043b8e0]: sqlite3_trace on 2050d640 for 'INSERT OR REPLACE INTO webappsstore2 (scope, key, value) VALUES ('moc.rettiwt.:https:443', '__connect_badge__:keep_badge_until', '{"until":1427263155109}') '
00182976 14:59:19.133 [4424] 2480[2043b8e0]: Statement::ExecuteStep error: database is locked
00182977 14:59:19.133 [4424] 2480[2043b8e0]: sqlite3_trace on 2050d640 for 'ROLLBACK'
ですよね。
そして、ツールバーボタンでチェックしようとしたら、
[TestLocalStorageAll]http://ja.wikipedia.org:80
[TestLocalStorageAll][xpconnect wrapped nsIURI]
[TestLocalStorageAll][xpconnect wrapped (nsISupports, nsIPrincipal, nsISerializable)]
NS_ERROR_STORAGE_BUSY: button.js:62:0
となって、
getLocalStorageForPrincipal() の時点でNS_ERROR_STORAGE_BUSYが発生した。

https://twitter.com:443 のスコープで、
sqlite3_trace on 2050d640 for 'INSERT OR REPLACE INTO webappsstore2 (scope, key, value) VALUES ('moc.rettiwt.:https:443', '__connect_badge__:keep_badge_until', '{"until":1427263155109}') '
Statement::ExecuteStep error: database is locked
sqlite3_trace on 2050d640 for 'ROLLBACK'
が起こったことと、
biscuit_deltaというTableで 'DELETE FROM biscuit_delta WHERE rowid=1'が起こったこととは、
直接の関係はないでしょう。

Googleスプレッドシートをいくつか開いておいたタブグループをカレントに切り替えた途端に発生した、というのは、それ以前に既にロックがリリースされない問題が起こっていて、
タブグループをカレントに切り替えた際に、
Table-webappsstore2,scope=moc.rettiwt.:https:443,key=__connect_badge__:keep_badge_until、の更新が起こり、
そこで、既に起こっている問題のせいで、'ExecuteStep error: database is lockedが返り、ROLLBACKがだされた、ということだと思います。

scope=moc.rettiwt.:https:443は、既に起こっている「ロックがリリースされない問題」の被害者であるだけ、という可能性もあります。
「ROLLBACKの後できちんとリクエストが再試行されて再実行されている」ということが確認できない、ということが、問題が起こる前におこっているかどうかを見ないと、どのあたりで問題が起こったのかを調べるのは難しいでしょう。
Table-webappsstore2,scope=moc.rettiwt.:https:443,key=__connect_badge__:keep_badge_until、の更新でSQLITE_BUSYが返り、それによって出されたROLLBACKでもSQLITE_BUSYが返って、ROLLBACKの無限リトライ、の可能性も、十分にありますけど、
ROLLBACKに対してSQLITE_BUSYが返り続けることの原因は、もっと以前に作り出されていると思います。

いずれにせよ、
00182975 14:59:19.133 [4424] 2480[2043b8e0]: sqlite3_trace on 2050d640 for 'INSERT OR REPLACE INTO webappsstore2 (scope, key, value) VALUES ('moc.rettiwt.:https:443', '__connect_badge__:keep_badge_until', '{"until":1427263155109}') '
00182976 14:59:19.133 [4424] 2480[2043b8e0]: Statement::ExecuteStep error: database is locked
00182977 14:59:19.133 [4424] 2480[2043b8e0]: sqlite3_trace on 2050d640 for 'ROLLBACK'
が起こり、
その後、http://ja.wikipedia.org:80のスコープの新規のアクセスができない、
ということが、極く普通にLocalStorageを更新しているだけで起こった、
というのは確実です。
ロジックでは、ROLLBACKではSQLITE_BUSYが返ってこなくなるまで無限リトライ、SQLITE_ABORTもSQLITE_ABORT_ROLLBACKも無視、ですから、現時点では何が起こっても不思議ではない状態なんでしょうね。