Project

General

Profile

バグ #1364

AppImage版にてMastodonアカウントの新規登録時、認証URLをクリックしても何も出ない

Added by で・じ・ きゃらっと 5 months ago. Updated 3 months ago.

Status:
終了
Priority:
通常
Target version:
プラグイン名:
ブランチ:
topic/1364-x
クラッシュする:
No

Files

1364-1-export-APPDIR.patch (1.22 KB) 1364-1-export-APPDIR.patch Yuto Tokunaga, 2019-08-16 13:01
1364-2-get-execso.patch (2.2 KB) 1364-2-get-execso.patch Yuto Tokunaga, 2019-08-21 12:54

再現手順

1. mikutter 3.9.0のAppImage(公式配布のx86_64版)をダウンロードし、実行権限をつける
2. AppImageをそのまま実行し、みくったーちゃんに従ってWorldを追加する
3. Mastodon -> 末代を選択し、認証URLのボタンを押すと、consoleに以下が出力され、ブラウザが開かない

XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/usr/lib/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to_point
Couldn't load XPCOM.

当方Manjaro (x86_64)ですが、あっきぃ製armv7lイメージをarchlinuxarmで実行しても、も同じようなエラーが出るようです。他の環境での類例も知りたいです。

Associated revisions

Revision 5057fec3 (diff)
Added by toshi_a 初音 4 months ago

Project X refs #1364

Revision c6ab72a9 (diff)
Added by toshi_a 初音 4 months ago

Project X refs #1364

Revision 1ab06086 (diff)
Added by Yuto Tokunaga 4 months ago

export APPDIR refs #1364

Revision ec2858ea (diff)
Added by Yuto Tokunaga 4 months ago

docker buildでmikutter/execsoからexec.soを取得するように変更 refs #1364

History

#1

Updated by で・じ・ きゃらっと 5 months ago

  • Subject changed from AppImage版にてMastodonアカウントの新規登録時、認証URLwo to AppImage版にてMastodonアカウントの新規登録時、認証URLをクリックしても何も出ない
  • 再現手順 updated (diff)
#2

Updated by で・じ・ きゃらっと 5 months ago

  • 再現手順 updated (diff)
#3

Updated by toshi_a 初音 5 months ago

OSC名古屋で、数人から同じと思われる問題の報告を受けています

#4

Updated by で・じ・ きゃらっと 5 months ago

軽く原因を追ってみました。

AppImageのビルドスクリプトである deployment/appimage/gen_appimage.sh は、

wget -q -O $APPDIR/usr/optional/exec.so https://github.com/darealshinji/AppImageKit-checkrt/releases/download/continuous/exec-x86_64.so

という形で exec.so のプリコンパイルドバイナリを引っ張ってきています。
これはAppImage内からAppImage外のプログラムを呼び出すときに使われるhookなのですが、これの説明文章によると、
export APPIMAGE_CHECKRT_DEBUG=1

を立てるとこの辺のcallがどうなってるか見られるよ、ということで、deployment/appimage/AppRun にこいつを仕掛けて Docker で AppImage を再生成し、consoleに出してみました。
このとき、こんなメッセージが出ました。

APPIMAGE_CHECKRT>> execv call hijacked: /usr/bin/xdg-open
APPIMAGE_CHECKRT>> execve call hijacked: /usr/bin/xdg-open
APPIMAGE_CHECKRT>> filename /usr/bin/xdg-open, canonical path /usr/bin/xdg-open
APPIMAGE_CHECKRT>> filename /usr/bin/xdg-open, fullpath /usr/bin/xdg-open
APPIMAGE_CHECKRT>> APPDIR = /tmp/.mount_mikuttOMhUWa
APPIMAGE_CHECKRT>> External process detected. Restoring env vars from parent 2775    <--- (A) 後述を参照
APPIMAGE_CHECKRT>> Reading env from parent process: /proc/2775/environ
APPIMAGE_CHECKRT>>     env var copied: SHELL=/bin/bash
APPIMAGE_CHECKRT>>     env var copied: SESSION_MANAGER=local/shia:@/tmp/.ICE-unix/585,unix/shia:/tmp/.ICE-unix/585
APPIMAGE_CHECKRT>>     env var copied: WINDOWID=60865717
APPIMAGE_CHECKRT>>     env var copied: COLORTERM=truecolor
APPIMAGE_CHECKRT>>     env var copied: XDG_CONFIG_DIRS=/etc/xdg
APPIMAGE_CHECKRT>>     env var copied: XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
APPIMAGE_CHECKRT>>     env var copied: XDG_MENU_PREFIX=xfce-
APPIMAGE_CHECKRT>>     env var copied: GTK_IM_MODULE=fcitx
APPIMAGE_CHECKRT>>     env var copied: LC_ADDRESS=ja_JP.UTF-8
APPIMAGE_CHECKRT>>     env var copied: LC_NAME=ja_JP.UTF-8
APPIMAGE_CHECKRT>>     env var copied: SSH_AUTH_SOCK=/tmp/ssh-fFfEPNLpHltK/agent.631
APPIMAGE_CHECKRT>>     env var copied: ARGV0=./mikutter-3.9.0-x86_64.AppImage
APPIMAGE_CHECKRT>>     env var copied: XMODIFIERS=@im=fcitx
(略)
APPIMAGE_CHECKRT>>     env var copied: LC_NUMERIC=ja_JP.UTF-8
APPIMAGE_CHECKRT>>     env var copied: _=/tmp/.mount_mikuttOMhUWa/usr/bin/ruby
APPIMAGE_CHECKRT>> Error restoring env vars from parent      <--- そして何故かコケている。
APPIMAGE_CHECKRT>> execve call hijacked: /usr/bin/gio
APPIMAGE_CHECKRT>> filename /usr/bin/gio, canonical path /usr/bin/gio
APPIMAGE_CHECKRT>> filename /usr/bin/gio, fullpath /usr/bin/gio
APPIMAGE_CHECKRT>> APPDIR = /tmp/.mount_mikuttOMhUWa
APPIMAGE_CHECKRT>> External process detected. Restoring env vars from parent 2807    <-- このプロセスはこのあと消える
APPIMAGE_CHECKRT>> Reading env from parent process: /proc/2807/environ
APPIMAGE_CHECKRT>>     env var copied: SHELL=/bin/bash
APPIMAGE_CHECKRT>>     env var copied: SESSION_MANAGER=local/shia:@/tmp/.ICE-unix/585,unix/shia:/tmp/.ICE-unix/585
APPIMAGE_CHECKRT>>     env var copied: WINDOWID=60865717
APPIMAGE_CHECKRT>>     env var copied: COLORTERM=truecolor
APPIMAGE_CHECKRT>>     env var copied: XDG_CONFIG_DIRS=/etc/xdg
APPIMAGE_CHECKRT>>     env var copied: XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
APPIMAGE_CHECKRT>>     env var copied: XDG_MENU_PREFIX=xfce-
APPIMAGE_CHECKRT>>     env var copied: GTK_IM_MODULE=fcitx
APPIMAGE_CHECKRT>>     env var copied: LC_ADDRESS=ja_JP.UTF-8
APPIMAGE_CHECKRT>>     env var copied: LC_NAME=ja_JP.UTF-8
APPIMAGE_CHECKRT>>     env var copied: SSH_AUTH_SOCK=/tmp/ssh-fFfEPNLpHltK/agent.631
APPIMAGE_CHECKRT>>     env var copied: ARGV0=./mikutter-3.9.0-x86_64.AppImage
APPIMAGE_CHECKRT>>     env var copied: XMODIFIERS=@im=fcitx
(略)
APPIMAGE_CHECKRT>>     env var copied: LC_NUMERIC=ja_JP.UTF-8
APPIMAGE_CHECKRT>>     env var copied: _=/tmp/.mount_mikuttOMhUWa/usr/bin/ruby
APPIMAGE_CHECKRT>> Error restoring env vars from parent
APPIMAGE_CHECKRT>> execve call hijacked: /usr/local/bin/gio-launch-desktop
APPIMAGE_CHECKRT>> filename /usr/local/bin/gio-launch-desktop, canonical path (null)
APPIMAGE_CHECKRT>> filename /usr/local/bin/gio-launch-desktop, fullpath /usr/local/bin/gio-launch-desktop
APPIMAGE_CHECKRT>> APPDIR = /tmp/.mount_mikuttOMhUWa
APPIMAGE_CHECKRT>> External process detected. Restoring env vars from parent 1    <--- 親プロセスがそもそも間違っている余り1から取得しようとしている
APPIMAGE_CHECKRT>> Reading env from parent process: /proc/1/environ
APPIMAGE_CHECKRT>> Error reading file: /proc/1/environ (許可がありません)
APPIMAGE_CHECKRT>> execve call hijacked: /usr/bin/gio-launch-desktop
APPIMAGE_CHECKRT>> filename /usr/bin/gio-launch-desktop, canonical path /usr/bin/gio-launch-desktop
APPIMAGE_CHECKRT>> filename /usr/bin/gio-launch-desktop, fullpath /usr/bin/gio-launch-desktop
APPIMAGE_CHECKRT>> APPDIR = /tmp/.mount_mikuttOMhUWa
APPIMAGE_CHECKRT>> External process detected. Restoring env vars from parent 1
APPIMAGE_CHECKRT>> Reading env from parent process: /proc/1/environ
APPIMAGE_CHECKRT>> Error reading file: /proc/1/environ (許可がありません)
APPIMAGE_CHECKRT>> execvp call hijacked: /usr/lib/firefox/firefox
APPIMAGE_CHECKRT>> execvpe call hijacked: /usr/lib/firefox/firefox
APPIMAGE_CHECKRT>> filename /usr/lib/firefox/firefox, canonical path /usr/lib/firefox/firefox
APPIMAGE_CHECKRT>> filename /usr/lib/firefox/firefox, fullpath /usr/lib/firefox/firefox
APPIMAGE_CHECKRT>> APPDIR = /tmp/.mount_mikuttOMhUWa
APPIMAGE_CHECKRT>> External process detected. Restoring env vars from parent 1
APPIMAGE_CHECKRT>> Reading env from parent process: /proc/1/environ
APPIMAGE_CHECKRT>> Error reading file: /proc/1/environ (Permission denied)

要するにこいつは何をやっているのかといいますと、xdg-open 等を mikutter (AppImage内)から呼び出したときの処理をフックし、実行しているmikutterの親プロセス(AppImage外)が持つ環境変数を持ってきて、xdg-open 等の環境変数にすり替えるものと思われます(軽く説明とコードを見る限りそんな感じでしたが、一部ライブラリのすり替えなどもこれでやるようです)。

ところで、上記のconsoleが出た直後のプロセス構造はこうなっていました。

$ pstree -p -a
systemd,1   <-- 後ろの方のhijackはここの環境変数を見に行っているが、もちろん取れるわけがない
  ├─ModemManager,270
(略)
  ├─mikutter-3.9.0-,2771 --debug
  │   └─{mikutter-3.9.0-},2772
(略)
  ├─xfce4-terminal,1276
(略)
  │   ├─bash,2446
  │   │   └─pstree,2904 -p -a
  │   ├─bash,2612  <-- (C) ここなら確実にAppImage外の環境変数なので問題ないはず。
  │   │   └─AppRun,2767 /tmp/.mount_mikuttOMhUWa/AppRun --debug   <-- (B) 本来ここの環境変数をを見てほしい
  │   │       └─ruby,2775/tmp/.mount_mikuttOMhUWa/usr/share/mikutte   <-- (A) ここはAppImageの檻の中。xdg-open は /usr/optional/exec.soにより、ここの環境変数を参照しようとしている
  │   │           ├─{ruby},2776    <-|
  │   │           ├─{ruby},2777    <-|-- おそらくこの4つのどこかで xdg-open が呼び出された
  │   │           ├─{ruby},2786    <-|
  │   │           └─{ruby},2898    <-|
(略)

上記と対比させるとなんとなくわかるでしょうか。 本来は(B)または(C)の環境変数を取りたいのに、(A)の環境変数を参照しているため正しく参照されない、ということが考えられます。
ruby は構造上多層プロセスで何やら動いているようですので(※僕はこの辺詳しくないです)、階層が多く、これが結果的に mikutter で Web ブラウザを呼び出せない原因なのではないかなと思います。

で、どないすんねんといいますと、

・AppRun(※mikutterツリー内のものとは別です)にこんなpatchがあるので、これのプレコンパイルしたものを噛んで動かすようAppImageを作ってみるとか、
https://github.com/darealshinji/AppImageKit-checkrt/blob/master/AppRun.c.patch

・それでだめなら、exec.so のソースのこのへんとか、
https://github.com/darealshinji/AppImageKit-checkrt/blob/master/exec.c#L82
このへんを
https://github.com/darealshinji/AppImageKit-checkrt/blob/master/env.c#L106
いい感じにmikutterに合うように騙すか、

・あるいは別の実装
https://cgit.kde.org/scratch/brauch/appimage-exec-wrapper.git/tree/exec.c
を使ってみるか

...だと今の所と思っていますが試行錯誤中です。

#5

Updated by toshi_a 初音 4 months ago

  • Status changed from 分類待ち to 実装待ち
#6

Updated by toshi_a 初音 4 months ago

  • Status changed from 実装待ち to レビュー待ち
  • Assignee set to で・じ・ きゃらっと
  • ブランチ set to topic/1364-x

なんかごめん

#7

Updated by 4pk mikutter 4 months ago

対策版のAppimageを使ってもmikutterからURLをクリックしてブラウザがうまく起動しませんでした。
ディストリビューションは、Gentoo Linux、kernel-5.0.0、SurfacePro3です。

#8

Updated by で・じ・ きゃらっと 4 months ago

手元の環境でも topic/1364-x ブランチを引いてbuildしてみましたが、4pkさん同様、やはりうまくいっていません。
OSC京都のとき、としぁさんの環境でうまくいっていたのはなんでだったんでしょう。あれが祭りのパワーというのでしょうか。

環境は上の再現手順と同じで、現象発生直後の pstree -p -a はこう出ました。

  ├─xfce4-terminal,9027
  │   ├─bash,9031
  │   │   └─pstree,9783 -p -a
  │   ├─bash,9522    <-- 本当はここの環境変数がほしい
  │   │   └─ruby,9711 -x/tmp/.mount_mikuttxdhx06/usr/share/miku  <-- たぶんここの環境変数を見てしまってる
  │   │       ├─{ruby},9724
  │   │       ├─{ruby},9728
  │   │       ├─{ruby},9736
  │   │       ├─{ruby},9779
  │   │       ├─{ruby},9781
  │   │       └─{ruby},9782

もう少し思案してみます。

#9

Updated by Yuto Tokunaga 4 months ago

exec.soを修正して解決しました.

再現手順

  1. AppImageをmikutter-*.AppImage --appimage-extractで展開する.
  2. https://github.com/yuntan/AppImageKit-checkrt をcloneし,make exec.soexec.soを生成する.
  3. exec.soをappimage内のusr/optional/exec.soにコピー.
  4. 添付したパッチをappimage内のAppRunに適用する.修正内容で重要な部分はexport APPDIRです.
  5. ./AppRunで起動.

手元のUbuntu 19.04で確認しました.

修正内容

ruby は構造上多層プロセスで何やら動いているようですので(※僕はこの辺詳しくないです)、階層が多く、これが結果的に mikutter で Web ブラウザを呼び出せない原因なのではないかなと思います。

で・じ・ きゃらっとさんの説明の通り,環境変数を参照する親プロセスが,AppImage内の環境で起動されているのが原因です.

そこで,取りたい環境変数が取れるまでプロセスツリーを遡るように修正しました. #1364-4pstree -p -aの例で説明すると,2776のプロセスでexecvをinjectした場合,2612のbashのプロセスまで遡り環境変数を取得します.

修正を適応した状態でexport APPIMAGE_CHECKRT_DEBUG=1してデバッグを見てもらうとどう動いてるか分かります.

#10

Updated by Yuto Tokunaga 4 months ago

修正内容のmikutterへの反映

AppImageKit-checkrtのコードを,要らない部分を削るなどして修正しリポジトリに取り込んでしまうのが良いと考えていますが,ライセンスをどう扱うかについては要相談です.

#11

Updated by toshi_a 初音 4 months ago

AppImageKit-checkrtのコードを,要らない部分を削るなどして修正しリポジトリに取り込んでしまうのが良いと考えていますが,

今もgithubからwgetして同梱しているだけなので、同じことをビルド手順上でもやってしまえばいいと思います。yuntanさんのリポジトリでやることに抵抗があるなら、organizerをmikutterにしても良いです。

ライセンスをどう扱うかについては要相談です.

本当だ、exec.soってライセンス特に書いてないのか……。

#12

Updated by toshi_a 初音 4 months ago

4pk mikutter さんは書きました:

対策版のAppimageを使ってもmikutterからURLをクリックしてブラウザがうまく起動しませんでした。
ディストリビューションは、Gentoo Linux、kernel-5.0.0、SurfacePro3です。

で・じ・ きゃらっと さんは書きました:

手元の環境でも topic/1364-x ブランチを引いてbuildしてみましたが、4pkさん同様、やはりうまくいっていません。
OSC京都のとき、としぁさんの環境でうまくいっていたのはなんでだったんでしょう。あれが祭りのパワーというのでしょうか。

環境は上の再現手順と同じで、現象発生直後の pstree -p -a はこう出ました。

[...]

もう少し思案してみます。

どうやら、あの時はホスト環境がUbuntu 18.04でしたが、これがビルド用DockerイメージのUbuntu 16.04の環境とよく似ていて、ライブラリを読みに行く場所は違うが、偶然ABI互換性があって起動できていただけだったようです。

#13

Updated by Yuto Tokunaga 4 months ago

本当だ、exec.soってライセンス特に書いてないのか……。

exec.c, env.cのヘッダにMITライセンスの記載がありました.改変して使って大丈夫そうです.

今もgithubからwgetして同梱しているだけなので、同じことをビルド手順上でもやってしまえばいいと思います。

dockerか何かでビルドするスクリプトを書いて,GitHubのリリースにexec.soを上げておきます.

yuntanさんのリポジトリでやることに抵抗があるなら、organizerをmikutterにしても良いです。

上記お願いします.

#14

Updated by toshi_a 初音 4 months ago

  • Assignee changed from で・じ・ きゃらっと to Yuto Tokunaga

Yuto Tokunaga さんは書きました:

本当だ、exec.soってライセンス特に書いてないのか……。

exec.c, env.cのヘッダにMITライセンスの記載がありました.改変して使って大丈夫そうです.

今もgithubからwgetして同梱しているだけなので、同じことをビルド手順上でもやってしまえばいいと思います。

dockerか何かでビルドするスクリプトを書いて,GitHubのリリースにexec.soを上げておきます.

yuntanさんのリポジトリでやることに抵抗があるなら、organizerをmikutterにしても良いです。

上記お願いします.

用意しました。このリポジトリのAdmin権限を付与しているので、よろしくおねがいします。
https://github.com/mikutter/AppImageKit-checkrt

#15

Updated by Yuto Tokunaga 4 months ago

GitHubからexec.soをダウンロードしてAppImageに含めるパッチです.

#16

Updated by toshi_a 初音 4 months ago

  • Assignee changed from Yuto Tokunaga to で・じ・ きゃらっと

チュートリアルを流して外部ブラウザが起動できることを確認できました。
topic/1364-x ブランチに頂いたパッチを取り込んだので、確認してみてください。

ただ、 #1371 の解決のためにRuby-GNOME2 3.3.7を使うようにしましたが、この問題が発生するようになってしまいました。原因は調査しきれていません。
一旦この問題は無視して、チュートリアルでブラウザがちゃんと開けるようになっていることを確認していただきたいです。

#17

Updated by toshi_a 初音 3 months ago

  • Status changed from レビュー待ち to 終了

世界中からちゃんと動いてる!と感動の声が寄せられているので、closeします。

Also available in: Atom PDF