Enpass on Gentooのクラッシュ問題がちょっとマシになった

以前、Linux版のEnpassはよく落ちるという愚痴を垂れ流したことがあります。

そのあとでUbuntu 20.04では落ちないからEnpass自体の問題じゃなくてGentooの問題かもということも書きました。

フォーラムに投稿しようかと思ったんですが、その前にいろいろ試行錯誤していたらだいぶマシになったのでその報告です。

せっかちさんへ

原因とかどうでもいいから使えるebuildファイルをよこせ、という人はこちらからどうぞ。

奮闘記

次に、解決に至るまでの記録をどうぞ。

まずコマンドラインから起動すると、クラッシュするときにこんなエラーが出るのを確認しました。

*** longjmp causes uninitialized stack frame ***: /opt/enpass/Enpass terminated

え、longjmpなんて使ってるの…と思ったとか思わなかったとか。

このエラーメッセージで検索をかけて、どこをどうたどったのか忘れたけどRed HatのBugzillaにたどり着きました。

そこで見つけたこんな投稿。

libcurl built without an asynchronous resolver library uses alarm() to time out DNS lookups. When a timeout occurs, this causes libcurl to jump from the signal handler back into the library with a sigsetjmp, which effectively causes libcurl to continue running within the signal handler. This is non-portable and could cause problems on some platforms. A discussion on the problem is available at http://curl.haxx.se/mail/lib-2008-09/0197.html

なるほどなるほど。

超訳すると「非同期版のDNSリゾルバーなしでビルドしたlibcurlを使うとこういうエラーが起きることがあるよ」

つまり、やっぱりEnpass自体の問題ではなかったと。

そしてGentooのcurlパッケージを見てみると、adnsというUSEフラグが見つかりました。

このフラグを有効にすると非同期版のリゾルバーを使えるようになるのかな？と思ってさっそく試すこと数日。

あれだけ落ちまくっていたEnpassがだいぶ安定しました。

というわけで、依存パッケージのUSEフラグをいじったものがこれです。

今でも時々落ちるけど、そのときのメッセージは別の内容で

double free or corruption (fasttop)

なんじゃこりゃ。解放済みの領域をもう一度解放しちゃったのかな。

そのうちこの原因も探ってみます。