これはJPGだからじゃなくて、スマホの小さなセンサーで暗所で高感度撮影してるからかな。風景だとストロボは届かないし
これはJPGだからじゃなくて、スマホの小さなセンサーで暗所で高感度撮影してるからかな。風景だとストロボは届かないし
うちのタンス2つで同じエラーが出るな… とりあえずissue投げた
https://github.com/tootsuite/mastodon/issues/6809
このアカウントは、notestockで公開設定になっていません。
gdbを使ったバグ追跡なんて自分の仕事でも罰ゲーム感あるのに、他人のしかもコンテナ内のC標準ライブラリのデバッグとかキツいにも程がある
コンテナにcoreファイルが出力されてるはずだし、コンテナにgdbをインストールしただけで他に特別なことはしてないから、後は誰か調査してくれ…
bt見た後にフレームの番号を押すと周辺のコードや変数の値がわかるんだっけか？ gdbなんて８年に１回くらいしか使わないのでもはや何も覚えてない
valgrindがmuslとうまく連動できてない故に発生したSEGVかもしれない。とりあえずvalgrindをいったん外そう
SEGVの起きたアドレス 0x00007fe8848d3bc0 は
プロセスメモリマップだと
[36msidekiq_mailers_1 |[0m 7fe8845d0000-7fe8847d2000 rw-p 00000000 00:00 0
[36msidekiq_mailers_1 |[0m 7fe8848d5000-7fe8849d6000 rw-p 00000000 00:00 0
の間の割り当てられてない空間だった。前後の領域と離れてるのでoff-by-oneなどではなさそう。
発生したけど、特に役立つ情報はないなあ… https://gist.github.com/tateisu/4c0a750624f6724227330c077e424ab6
muslだからかfree()のredirに失敗してるしヒープチェックもうまくできなさそう
sidekiqがSegmentation faultで落ちるのはウチでも起きてた
https://gist.github.com/tateisu/e1c9b2df3284fbc679bc55d6879c78a6
rubyのスタックトレースは発生個所が安定しないのでメモリ破壊の類だと思われる
Dockerfileを変更してaptに valgrindパッケージを追加
docker-compose.ymlを変更してbundle exec sidekiq をvalgrind --log-fd=1 -v bundle exec sidekiq にする
ビルド、起動、ログ確認してvalgrind由来のログが含まれているのを確かめた
Segmentation fault が起きるのを待つ ←今ココ
役に立つログが取れるかどうかはまだ分からない
トイザらスが全米の店舗を閉鎖http://blog.livedoor.jp/goldennews/archives/52031498.html
アメリカも少子化の波が押し寄せてるんだなあ…？
小メモリ環境なら、 pgbouncer 必須で、 pgbouncer + pgsql に 128MB rails + sidekiq に 256+256 MB streaming に 64MB ES に 512 MB Web Server に 128 MB くらいで Docker で mem_limit かけるといい塩梅だと思う。（私感。ただし、遅く感じると思う。）