2009-08-14 9 views
0

Mac OS XおよびiPhone OSに同梱されているICUライブラリに基づいて構築された素晴らしいRegexKitLiteフレームワークを使用しています。これは、マッチを検索するときに断続的に表示されるこのエラーの例外を除いて、これまで順風満帆されています:RegexKitLiteアサーションエラーが断続的に発生する

Internal Error 
Invalid parameter not satisfying: 
(cacheSlot->setToHash == buffer->hash) && (cacheSlot->setToLength == buffer->length) && (cacheSlot->setToUniChar == buffer->uniChar) 

これを引き起こしている可能性がありますどのような任意のアイデア?

+0

使用している文字列の種類は特にユニークですか?複数のスレッドで同じ操作を実行しようとしている可能性はありますか? – dreamlax

+0

これはRegexKitLiteの問題のように思えますが、regexes per sとは関係ありません。 RegexKitLite専用のサイトでは、おそらく運が良いでしょう。 –

答えて

1

:私はRegexKitLiteの著者です。

これは、RegexKitLite内の内部アサーションエラーです。組み込みの内部アサーションチェックはたくさんあります。これは、キャッシュされたコンパイル済みの正規表現をキャッシュから取得した後、検索されたキャッシュされた正規表現が何らかの理由で正しく設定されていないということです。

あなたができる最良のことは、sourceforge.net RegexKit bug trackerにバグレポートを送信することです。可能であれば、バグを再現するテストケースを提出してください。これは青い推測のうち野生のものですが、アサーションメッセージに基づいて、range:パラメータを使用しているマッチ操作と関係があり、その範囲は常に「動いています」その範囲は、2048文字前後の小/大バッファサイズを横切る可能性があります。また、Unicode文字を含む文字列を検索し、RegexKitLiteが文字列ダイレクトバッファを使用している可能性があります。可変文字列であり、バッキングバッファは再割り当てされます。それが成長した、または収縮した...または "非Unicode"だった可変文字列が変更され、現在Unicode文字を含んでいて、キャッシュされたUTF-16から文字列直接バッファへの切り替えが行われます。

うまくいけばこれは、アサーションの失敗を引き起こしているコーナーケースを絞り込むのに役立ちます。少なくとも、それはdetecです問題を引き起こしたり、偽の結果文字列を返すことはありません。 :)

関連する問題