SlideShare a Scribd company logo
1 of 36
Download to read offline
ゆるバグ
バグについてゆるく語り合う会
#yurubug
2020/4/29, 2020/5/06
光成滋生
• Windows Xpのバグ
• gdbのバグ
• objdumpのバグ
• Windowsのstackの仕様
• Linux on Travis-CIでだけエラー
• inline化される?
• Visual Studioのバグ
• PHPのバグ
遭遇したもの
2 / 36
• 発端
• 当時(2001) Windows 2000でとあるコーデックを開発中
• ソースコードのインデントがおかしかったのでツールで整形
• 一部手動でスペースをタブに変換するなど
• コーデック自体の挙動が変わるはずはない
• しかし
• 実行するとWindows 2000が突如再起動
• ???
• Windows 98みたいにすぐ落ちることはあまりないんだけど
• もう一度試してもやっぱり再起動
• 整形までだとちゃんと動く
• ???
整形したらえらいことになった
3 / 36
• リブートを繰り返しつつコードを小さくする
• 再起動待ち辛い
• ディスクが壊れないかも心配
• 原因判明
• コーデックは無関係
• コーデックの進捗状況を示すメッセージで
スペースだったところをタブにしたら発生
原因追求
4 / 36
• 文字を出力するだけ
• 後にループしなくてもOKと判明
• 発売直前の(開発用)Windows Xpでも発生
• こんなのでOSが落ちるの?
コード最小化
#include <stdio.h>
int main(void)
{
for (;;) {
printf("hung up¥t¥t¥b¥b¥b¥b¥b¥b");
}
return 0;
}
5 / 36
• ML(メーリングリスト) ; 今のTwitterみたいなもの
• fj.os.ms-windows.programming
• https://groups.google.com/forum/#!msg/fj.os.ms-
windows.programming/0c2WdfjwK4Q/fC7sHDh2jkgJ
• omp.os.ms-windows.programmer.win32
• https://groups.google.com/forum/#!msg/comp.os.ms-
windows.programmer.win32/uZd_19YEdRM/JXBR0FTsV2sJ
• 反応
• this is not just a joke
• NT4でも落ちた
• printf("¥t¥b¥b");だけでも落ちた
• Perlでも落ちた / ○○でも落ちた / 言語に依らない
• 実は結構なセキュリティホールだったかも
fjなどのニュースグループに投稿
6 / 36
• よくある日常
• あるプログラムが落ちたのでデバッグしようとgdb上で起動
• まずはrで実行して落ちたところでバックトレース(bt)
• あれ、Command not foundって何?
• よくみるとコマンドプロンプトに戻ってる
いつもと違うgdb
% gdb ./a.out
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
...
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...Segmentation fault (core dumped)
% r
r: Command not found.
% bt
bt: Command not found.
%
7 / 36
• 再掲
• dmesgを見てみる
よく見ると落ちているのはgdb
Reading symbols from
./a.out...Segmentation fault (core dumped)
% dmesg | tail
[8895844.655909] gdb[18402]: segfault at 7ffc284a1ff8
ip 0000000000741fc7 sp 00007ffc284a1fc0 error 6 in
gdb[400000+5a0000]
8 / 36
• 何が原因だろう
• 10万行以上あるコードを減らす
• 少し削る & コンパイル & gdbで実行
• 落ちる → もっと削る
• 落ちない → 少し戻す
• なかなか辛い
原因調査
9 / 36
• 中身に意味はないがgdb 7.7が落ちるコード
削られたコード
#include <utility>
#include <stdio.h>
struct BaseHolder { };
template<class Func>
struct Holder : public BaseHolder {
Func func;
explicit Holder(Func&& func):func(std::forward<Func>(func)) {}
};
struct Runner {
BaseHolder *holder_;
template<class Func>
explicit Runner(Func && func):holder_(new Holder<Func>(func)) {}
~Runner() { delete holder_; }
};
template<class T>void f(T &) {
auto g =[&](){};
Runner{g};
}
int main() {
int a = 0;
f(a);
}
10 / 36
• C++11のtemplateとラムダ関数の組み合わせでできる
シンボルが複雑でgdbのパーサがおかしくなった
• それっぽいキーワードで探すと同時期に似たバグ報告
• https://sourceware.org/bugzilla/show_bug.cgi?id=16845
• バージョンを上げて解決
原因の推測
11 / 36
• AVX-512の命令エンコーディングはとても複雑
• Xbyakのブロードキャスト(レジスタ全体に伝搬させる)
指定のテストでobjdumpで逆アセンブルしながら確認中
• なんかテストがたまに失敗する
• しかし落ちたところを取り出してテストしてもpass
• うーん
• 調査中(略)
時々失敗するテスト
12 / 36
• 原因判明
• 同じバイト列なのに逆アセンブル結果が違う
• vcvtpd2dqxとvcvtpd2dq / vcvtpd2dqyとvcvtpd2dq
• 途中に(Z)のバイト列が入るとそのあと間違えるバグ
• 逆アセンブラが状態を持つとは思わなかった
時々間違えるobjdump (2.3.0)
% objdump -M x86-64 -D -b binary -m i386 vcvtpd2dq.bin
vcvtpd2dq.bin: file format binary
Disassembly of section .data:
00000000 <.data>:
0: 67 c5 fb e6 40 20 vcvtpd2dqx 0x20(%eax),%xmm0 ; (X)
6: 67 c5 ff e6 40 20 vcvtpd2dqy 0x20(%eax),%xmm0 ; (Y)
c: 67 62 f1 ff 18 e6 40 vcvtpd2dq 0x20(%eax){1to2},%xmm0 ; (Z)
13: 04
14: 67 c5 fb e6 40 20 vcvtpd2dq 0x20(%eax),%xmm0 ; (X')
1a: 67 c5 ff e6 40 20 vcvtpd2dq 0x20(%eax),%xmm0 ; (Y')
13 / 36
• inconsistent disassemble of vcvtpd2dq
• https://sourceware.org/bugzilla/show_bug.cgi?id=23025
報告したら速攻で修正された
14 / 36
• 普段はちゃんと動いているのにたまに落ちる
• それ自体はpureな関数(状態を持たない)
• アライメントなどの問題ではない
• Windowsでだけ発生
• バッファオーバーフローでもない
• スタックオーバーフローでもない
• 静的解析ツールの警告で原因判明
• 問題が発生する最小コード
たまに例外で落ちる自分のコード
foo:
sub rsp, 1024 * 6
mov rax, [rsp]
add rsp, 1024 * 6
ret
15 / 36
• スタックレイアウト
• スタックの割り当ては4KiBずつ
• 新しいスタックは4KiBずつ伸ばさなければならない
Windowsのstackは自動的に伸びる
←現在のスタック
←過去に使われたところのあるスタックの先端
小さいアドレス
大きいアドレス
ここから↓はまだ割り当てられていないページ
16 / 36
• スタックレイアウト
Windowsで16KiBのスタックが欲しいとき
←現在のスタック
←過去に使われたところのあるスタックの先端
ここから↓はまだ割り当てられていないページ
-4096 ; まずここまで
-4096*2 ; 次にここ
-4096*3 ; そしてここ
こんなふうにして伸ばす
foo:
sub rsp, 1024 * 16
mov rax, [rsp + 1024 * 15]
mov rax, [rsp + 1024 * 14]
...
17 / 36
• 関数のプロローグ
• 元のコードが時々落ちていたのは
• 普段は他のコードがスタックを利用してスタック領域が伸び
ていた大丈夫
• 通常と異なるパスでスタックがあまり伸びてないときに突入
• 落ちる
専用の関数__chkstkがある
foo:
mov [rsp+8], ecx
mov eax, STACK_SIZE
call __chkstk
sub rsp, rax
...
18 / 36
• https://github.com/herumi/test-travis-release
• GoからCの関数を呼ぶサンプル
• 手元のUbuntu(x64, arm64), macOS, Windows(mingw)
で動作
Travis-CIで悩み中の問題
/*
void blsFunc(const char buf[][8]);
*/
import "C"
import (
"unsafe"
)
func BlsFunc(buf []byte) {
C.blsFunc((*[8]C.char)(unsafe.Pointer(&buf[0])))
}
19 / 36
• Travis-CIでの結果
• Goやコンパイラのバージョンを合わせても駄目
• Goの中間生成物を見る
• _obj/にいろいろファイルができる
• 関係ある部分を眺める
なぜかTravis-CI/Linux上でのみエラー
cd bls
go tool cgo bls
20 / 36
• 何かのツールがchar [][8]のパースに失敗してる?
• でもなんで??? 詳しい人プリーズ
違い
// bls.cgo1.goのOKなとき
v := (_Cfunc_blsFunc)((*[8] _Ctype_char)(unsafe.Pointer(&buf[0])))
// ERRなとき
v := func() _Ctype_int{
_cgoIndex0 := &buf;
_cgo0 := (*[8]_Ctype_char)(unsafe.Pointer(&(*_cgoIndex0)[0]));
_cgoCheckPointer(_cgo0, *_cgoIndex0); ...
}()
// bls.cgo2.cのOKなとき
_cgo_..._Cfunc_blsFunc(void *v) {
struct { __typeof__(char const[8])* p0; ...
// ERRなとき
_cgo_..._Cfunc_blsFunc(void *v) {
struct { void* p0; ...
21 / 36
• gccのバージョンを上げたらある処理が4倍遅くなった
• gccが生成する関数のそれぞれのasm出力は問題なさそう
• バージョンが変わっても大差ない
• 謎のベンチマーク挙動
• ベンチマークの後ろに
exit()を挿入すると速度が変わる
• 挿入箇所と効果の関係は?
• (B)でexitすると遅いまま
• (C)でexitすると速い
• (D)でexitすると(C)より少し遅い
• (E)でexitすると(C)よりもう少し遅い
おかしな因果関係?
void bench() {
(A)ベンチマークコード
// (B)
}
int main() {
bench();
// (C)
unitTest1();
// (D)
unitTest2();
// (E)
unitTest3();
}
22 / 36
• gccはinline対象関数の総量を管理している
• --param max-inline-insns-single=N オプション
• この範囲内でinline化する関数を選んでいる
• 原因判明
• gccのバージョンが上がってinline対象となる関数が増えた
• bench内の関数がinline対象外となり遅くなった
• 単体でみるとそれは分からない
• exitすると速くなったり遅くなったりした理由
• mainの途中でexitした後のコードは生成されない
• inline対象が減るのでbenchがinline化されて速くなる
• bench内でexitしてもmain内でのinline対象は減らなかった
• benchは速くならない
• -Winlineで該当関数がinlineされているか確認
inlineされるかされないか
23 / 36
• Visual Studioでsinやexpが遅くなる現象
• 理由がさっぱり分からない
• とても苦労して見つけた再現コード
• struct A notUsedを作るとmainの中のsin等が遅くなる
• ループ回数の8を7にすると遅くならない
何故か遅くなる数学関数
const struct A {
float a[8];
A() {
const float x = log(2.0);
for (int i = 0; i < 8; i++) a[i] = x;
}
} notUsed;
int main() {
...
}
24 / 36
• ループ回数8と7で違いがでる要因といえば
• AVX2を適用可能かどうか
• 原因判明
• VCは8回ループをAVX2を使って最適化した
• しかしSSEに切り戻すコード(vzeroupper)を入れ忘れ
VCの最適化バグ
25 / 36
• レジスタの形
• SSEは128bitレジスタxmm
• AVXは256bitレジスタymm
• ymmの下位128bitがxmmレジスタ
• SSEの命令padddはxmmレジスタ同士の足し算
• AVXの命令vpadddはymmレジスタ同士の足し算
• SSE命令はymmの上位128bitの存在を知らない
• その部分(d7:d6:d5:d4)は変更されない
SSEとAVX
xmm0 [d3:d2:d1:d0] ; diは32bit
ymm0 [d7:d6:d5:d4:d3:d2:d1:d0]
26 / 36
• x86はレジスタの一部しか書き換えない操作は苦手
• 32bitレジスタの下位16bitのみを操作する
• フラグの一部しか更新しないinc/decなど
• ちょっと遅くなる(だけだった)
パーシャルレジスタストール
27 / 36
• 上位128bitがclean(zero)な状態と
そうじゃないdirtyな状態
• SSE/AVX両方動くけれども
dirtyなときにSSEを使うと大きなペナルティ
• AVXを利用後SSEに戻るときにvzeroupperを呼ぶ必要
• VCのバグ
• notUsed内でAVXを利用したがvzeroupperせずにmainに突入
CPUは状態を持っている
clean
upper
dirty
upper
AVX使用
vzeroupper
SSE AVX
SSE
速度低下
28 / 36
• Broadwellまで Skylake(2015~)以降
• Intel 64 and IA-32最適化マニュアル
• MIXING AVX CODE WITH SSE CODE
(Skylake/Ice Lake)以降は改善されてる
29 / 36
• Intelシステムプログラミングガイド
• Performance Monitoring Events
• C1H:08H ; OTHER_ASSISTS.AVX_TO_SSE
• CPU内でAVX→SSEでペナルティを受けた回数を記録してる
• perf stat -e r08c1 -e r10c1 ./実行ファイル
• perfが動かない場合(VM上など)はsdeを使う
• https://software.intel.com/en-us/articles/intel-software-development-emulator
• sde -oast out.txt -- ./実行ファイル
• # AVX_to_SSE_transition_instances: 10000005
perfやsdeによる検出方法
Ice Lakeでは無くなった
30 / 36
• PHPで実行時にコードをコンパイルして共有メモリに
保存して再利用する機能
• PHP5.5(当時)でOPcacheを利用しているとsegvする現象
• どうにかしたい
• 調査開始
• segvからbtしたぐらいでは分からない(PHPは巨大)
• ASan(address sanitizer –faddress=sanitize)で実行
• <?php echo “abc”;だけで落ちる
• ASanを封じられた
• LD_PRELOADでtcmallocやjemallocなどのデバッグ支援機構
• エラーで落ちた
• 仕方がないので自前malloc/freeを作成
PHPのOPcacheにまつわる問題
31 / 36
• malloc/freeだけではない
• memalign, aligned_alloc, posix_memalignなど
• 偽陽性が高い?
• mallocしてないのにfreeに渡される知らないポインタ
• strdupもラップが必要だった
• -Dmalloc=my_malloc –Dfree=my_free ...
• 偽陽性消える
• 作業中にPHPのバグをいくつか見つける
• いろいろなmalloc/free
• Apache APR, MySQL由来のpstrdupなどの外部ライブラリ
• PHP内部のfree, interned_free, ...
• 整合性を保つよう調整
ラップが難しい(1/2)
32 / 36
• dlopen
• dlopenの中でもmalloc
• デバッグ用にfprintfするとfprintfで先にmallocされて順序が変
わる
• 戦略
• (コードレベルで)全てのmalloc, freeを置き換える
• LD_PRELOADで自前のmalloc/freeに置き換え
• これで普通のプログラムは落ちなくなった
• ASanで落ちていた(ASanの誤動作)の場所も判明
ラップが難しい(2/2)
33 / 36
• 泥臭い方法
• ASLRを無効化しておく
• sudo sh -c "echo 0 > /proc/sys/kernel/randomize_va_space"
• 実行
• おかしなfreeを受けたところでそのポインタを記録
• そのポインタをmallocした箇所でbreak & btで該当ソース
• 主な結論
• PHPのオプションのfast_shutdownが有効なときに
malloc/freeの不一致コードに突入
• コードがカオスなので修正時間は無い
• いくつかバグ報告したしまあいいか
• fast_shutdown=0で回避可能
当時の解決
34 / 36
• clang
• dlopenにRTLD_DEEPBINDをつけるとエラー
• 昔はこれで誤検知?
• typo発見 incompatibe → incompatible
• macOSのdlopenは最初からRTLD_DEEPBIND相当の挙動
• gccのdlopenにはこの制約はなさそう
最近のclang/gcc
shared library with RTLD_DEEPBIND flag which is
incompatibe with sanitizer runtime (see
https://github.com/google/sanitizers/issues/611 for
details).
35 / 36
• RTLD_DEEPBIND
• dlopenするライブラリのシンボルの参照領域を
グローバル領域よりも前に配置する
• 例
• RTLD_DEEPBINDなし ; clock()は123を返す
• RTLD_DEEPBINDあり ; clock()はオリジナルの値を返す
補足
main.c
h = dlopen("sub.so");
f = dlsym(h, "sub");
f();
sub.c // sub.so
void sub() {
int t = (int)clock();
printf("clock()=%d¥n", t);
}
pred.c // pred.so
clock_t clock() { return 123; }
LD_PRELOAD=./pred.so ./main
36 / 36

More Related Content

What's hot

どうして昔の人は八進数でしゃべるのか?
どうして昔の人は八進数でしゃべるのか?どうして昔の人は八進数でしゃべるのか?
どうして昔の人は八進数でしゃべるのか?たけおか しょうぞう
 
RSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjpRSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjpsonickun
 
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCマイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCdisc99_
 
GPUが100倍速いという神話をぶち殺せたらいいな ver.2013
GPUが100倍速いという神話をぶち殺せたらいいな ver.2013GPUが100倍速いという神話をぶち殺せたらいいな ver.2013
GPUが100倍速いという神話をぶち殺せたらいいな ver.2013Ryo Sakamoto
 
Xbyakの紹介とその周辺
Xbyakの紹介とその周辺Xbyakの紹介とその周辺
Xbyakの紹介とその周辺MITSUNARI Shigeo
 
MySQLerの7つ道具
MySQLerの7つ道具MySQLerの7つ道具
MySQLerの7つ道具yoku0825
 
ゲーム開発者のための C++11/C++14
ゲーム開発者のための C++11/C++14ゲーム開発者のための C++11/C++14
ゲーム開発者のための C++11/C++14Ryo Suzuki
 
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
DSIRNLP #3 LZ4 の速さの秘密に迫ってみるDSIRNLP #3 LZ4 の速さの秘密に迫ってみる
DSIRNLP #3 LZ4 の速さの秘密に迫ってみるAtsushi KOMIYA
 
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツールC/C++プログラマのための開発ツール
C/C++プログラマのための開発ツールMITSUNARI Shigeo
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪Takuto Wada
 
Intro to SVE 富岳のA64FXを触ってみた
Intro to SVE 富岳のA64FXを触ってみたIntro to SVE 富岳のA64FXを触ってみた
Intro to SVE 富岳のA64FXを触ってみたMITSUNARI Shigeo
 
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するCEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するYoshifumi Kawai
 
カスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについてカスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについてalwei
 
C++の話(本当にあった怖い話)
C++の話(本当にあった怖い話)C++の話(本当にあった怖い話)
C++の話(本当にあった怖い話)Yuki Tamura
 
C++でテスト駆動開発
C++でテスト駆動開発C++でテスト駆動開発
C++でテスト駆動開発Akineko Shimizu
 
Xeon PhiとN体計算コーディング x86/x64最適化勉強会6(@k_nitadoriさんの代理アップ)
Xeon PhiとN体計算コーディング x86/x64最適化勉強会6(@k_nitadoriさんの代理アップ)Xeon PhiとN体計算コーディング x86/x64最適化勉強会6(@k_nitadoriさんの代理アップ)
Xeon PhiとN体計算コーディング x86/x64最適化勉強会6(@k_nitadoriさんの代理アップ)MITSUNARI Shigeo
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」Masahito Zembutsu
 
ROS2のリアルタイム化に挑む WG初参加
ROS2のリアルタイム化に挑む WG初参加ROS2のリアルタイム化に挑む WG初参加
ROS2のリアルタイム化に挑む WG初参加Atsushi Hasegawa
 

What's hot (20)

どうして昔の人は八進数でしゃべるのか?
どうして昔の人は八進数でしゃべるのか?どうして昔の人は八進数でしゃべるのか?
どうして昔の人は八進数でしゃべるのか?
 
RSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjpRSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjp
 
マイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPCマイクロサービスバックエンドAPIのためのRESTとgRPC
マイクロサービスバックエンドAPIのためのRESTとgRPC
 
GPUが100倍速いという神話をぶち殺せたらいいな ver.2013
GPUが100倍速いという神話をぶち殺せたらいいな ver.2013GPUが100倍速いという神話をぶち殺せたらいいな ver.2013
GPUが100倍速いという神話をぶち殺せたらいいな ver.2013
 
Glibc malloc internal
Glibc malloc internalGlibc malloc internal
Glibc malloc internal
 
Xbyakの紹介とその周辺
Xbyakの紹介とその周辺Xbyakの紹介とその周辺
Xbyakの紹介とその周辺
 
MySQLerの7つ道具
MySQLerの7つ道具MySQLerの7つ道具
MySQLerの7つ道具
 
Gpu vs fpga
Gpu vs fpgaGpu vs fpga
Gpu vs fpga
 
ゲーム開発者のための C++11/C++14
ゲーム開発者のための C++11/C++14ゲーム開発者のための C++11/C++14
ゲーム開発者のための C++11/C++14
 
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
DSIRNLP #3 LZ4 の速さの秘密に迫ってみるDSIRNLP #3 LZ4 の速さの秘密に迫ってみる
DSIRNLP #3 LZ4 の速さの秘密に迫ってみる
 
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツールC/C++プログラマのための開発ツール
C/C++プログラマのための開発ツール
 
例外設計における大罪
例外設計における大罪例外設計における大罪
例外設計における大罪
 
Intro to SVE 富岳のA64FXを触ってみた
Intro to SVE 富岳のA64FXを触ってみたIntro to SVE 富岳のA64FXを触ってみた
Intro to SVE 富岳のA64FXを触ってみた
 
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するCEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
 
カスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについてカスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについて
 
C++の話(本当にあった怖い話)
C++の話(本当にあった怖い話)C++の話(本当にあった怖い話)
C++の話(本当にあった怖い話)
 
C++でテスト駆動開発
C++でテスト駆動開発C++でテスト駆動開発
C++でテスト駆動開発
 
Xeon PhiとN体計算コーディング x86/x64最適化勉強会6(@k_nitadoriさんの代理アップ)
Xeon PhiとN体計算コーディング x86/x64最適化勉強会6(@k_nitadoriさんの代理アップ)Xeon PhiとN体計算コーディング x86/x64最適化勉強会6(@k_nitadoriさんの代理アップ)
Xeon PhiとN体計算コーディング x86/x64最適化勉強会6(@k_nitadoriさんの代理アップ)
 
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
 
ROS2のリアルタイム化に挑む WG初参加
ROS2のリアルタイム化に挑む WG初参加ROS2のリアルタイム化に挑む WG初参加
ROS2のリアルタイム化に挑む WG初参加
 

Similar to ゆるバグ

LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)Takeshi Yamamuro
 
Android デバッグ小ネタ
Android デバッグ小ネタAndroid デバッグ小ネタ
Android デバッグ小ネタl_b__
 
zend_parse_parametersと64bit環境
zend_parse_parametersと64bit環境zend_parse_parametersと64bit環境
zend_parse_parametersと64bit環境Yo Ya
 
Java をクラッシュさせて遊んでみよう!
Java をクラッシュさせて遊んでみよう!Java をクラッシュさせて遊んでみよう!
Java をクラッシュさせて遊んでみよう!YujiSoftware
 
StackExchangeで見たシステムプログラミング案件
StackExchangeで見たシステムプログラミング案件StackExchangeで見たシステムプログラミング案件
StackExchangeで見たシステムプログラミング案件yaegashi
 
vImageのススメ(改訂版)
vImageのススメ(改訂版)vImageのススメ(改訂版)
vImageのススメ(改訂版)Shuichi Tsutsumi
 
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka [cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka CODE BLUE
 
Exploring the x64
Exploring the x64Exploring the x64
Exploring the x64FFRI, Inc.
 
Spmv9forpublic
Spmv9forpublicSpmv9forpublic
Spmv9forpublicT2C_
 
Unix32 v 20100508
Unix32 v 20100508Unix32 v 20100508
Unix32 v 20100508xylnao
 
これからのコンピューティングとJava(Hacker Tackle)
これからのコンピューティングとJava(Hacker Tackle)これからのコンピューティングとJava(Hacker Tackle)
これからのコンピューティングとJava(Hacker Tackle)なおき きしだ
 
Inside of excel 方眼紙撲滅委員会 #pyfes
Inside of excel 方眼紙撲滅委員会 #pyfesInside of excel 方眼紙撲滅委員会 #pyfes
Inside of excel 方眼紙撲滅委員会 #pyfesTakeshi Komiya
 
[CEDEC2017] LINEゲームのセキュリティ診断手法
[CEDEC2017] LINEゲームのセキュリティ診断手法[CEDEC2017] LINEゲームのセキュリティ診断手法
[CEDEC2017] LINEゲームのセキュリティ診断手法LINE Corporation
 
あるRISC-V CPUの 浮動小数点数(異常なし)
あるRISC-V CPUの 浮動小数点数(異常なし)あるRISC-V CPUの 浮動小数点数(異常なし)
あるRISC-V CPUの 浮動小数点数(異常なし)たけおか しょうぞう
 
【Unity道場スペシャル 2017京都】乱数完全マスター 京都編
【Unity道場スペシャル 2017京都】乱数完全マスター 京都編【Unity道場スペシャル 2017京都】乱数完全マスター 京都編
【Unity道場スペシャル 2017京都】乱数完全マスター 京都編Unity Technologies Japan K.K.
 
Wavelet matrix implementation
Wavelet matrix implementationWavelet matrix implementation
Wavelet matrix implementationMITSUNARI Shigeo
 
【Unity道場スペシャル 2017札幌】乱数完全マスター
【Unity道場スペシャル 2017札幌】乱数完全マスター 【Unity道場スペシャル 2017札幌】乱数完全マスター
【Unity道場スペシャル 2017札幌】乱数完全マスター Unity Technologies Japan K.K.
 

Similar to ゆるバグ (20)

From IA-32 to avx-512
From IA-32 to avx-512From IA-32 to avx-512
From IA-32 to avx-512
 
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
LLVMで遊ぶ(整数圧縮とか、x86向けの自動ベクトル化とか)
 
Android デバッグ小ネタ
Android デバッグ小ネタAndroid デバッグ小ネタ
Android デバッグ小ネタ
 
zend_parse_parametersと64bit環境
zend_parse_parametersと64bit環境zend_parse_parametersと64bit環境
zend_parse_parametersと64bit環境
 
Java をクラッシュさせて遊んでみよう!
Java をクラッシュさせて遊んでみよう!Java をクラッシュさせて遊んでみよう!
Java をクラッシュさせて遊んでみよう!
 
StackExchangeで見たシステムプログラミング案件
StackExchangeで見たシステムプログラミング案件StackExchangeで見たシステムプログラミング案件
StackExchangeで見たシステムプログラミング案件
 
vImageのススメ(改訂版)
vImageのススメ(改訂版)vImageのススメ(改訂版)
vImageのススメ(改訂版)
 
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka [cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
[cb22] Wslinkのマルチレイヤーな仮想環境について by Vladislav Hrčka
 
Exploring the x64
Exploring the x64Exploring the x64
Exploring the x64
 
Spmv9forpublic
Spmv9forpublicSpmv9forpublic
Spmv9forpublic
 
Unix32 v 20100508
Unix32 v 20100508Unix32 v 20100508
Unix32 v 20100508
 
これからのコンピューティングとJava(Hacker Tackle)
これからのコンピューティングとJava(Hacker Tackle)これからのコンピューティングとJava(Hacker Tackle)
これからのコンピューティングとJava(Hacker Tackle)
 
LLVM最適化のこつ
LLVM最適化のこつLLVM最適化のこつ
LLVM最適化のこつ
 
Node.jsでブラウザメッセンジャー
Node.jsでブラウザメッセンジャーNode.jsでブラウザメッセンジャー
Node.jsでブラウザメッセンジャー
 
Inside of excel 方眼紙撲滅委員会 #pyfes
Inside of excel 方眼紙撲滅委員会 #pyfesInside of excel 方眼紙撲滅委員会 #pyfes
Inside of excel 方眼紙撲滅委員会 #pyfes
 
[CEDEC2017] LINEゲームのセキュリティ診断手法
[CEDEC2017] LINEゲームのセキュリティ診断手法[CEDEC2017] LINEゲームのセキュリティ診断手法
[CEDEC2017] LINEゲームのセキュリティ診断手法
 
あるRISC-V CPUの 浮動小数点数(異常なし)
あるRISC-V CPUの 浮動小数点数(異常なし)あるRISC-V CPUの 浮動小数点数(異常なし)
あるRISC-V CPUの 浮動小数点数(異常なし)
 
【Unity道場スペシャル 2017京都】乱数完全マスター 京都編
【Unity道場スペシャル 2017京都】乱数完全マスター 京都編【Unity道場スペシャル 2017京都】乱数完全マスター 京都編
【Unity道場スペシャル 2017京都】乱数完全マスター 京都編
 
Wavelet matrix implementation
Wavelet matrix implementationWavelet matrix implementation
Wavelet matrix implementation
 
【Unity道場スペシャル 2017札幌】乱数完全マスター
【Unity道場スペシャル 2017札幌】乱数完全マスター 【Unity道場スペシャル 2017札幌】乱数完全マスター
【Unity道場スペシャル 2017札幌】乱数完全マスター
 

More from MITSUNARI Shigeo

暗号技術の実装と数学
暗号技術の実装と数学暗号技術の実装と数学
暗号技術の実装と数学MITSUNARI Shigeo
 
範囲証明つき準同型暗号とその対話的プロトコル
範囲証明つき準同型暗号とその対話的プロトコル範囲証明つき準同型暗号とその対話的プロトコル
範囲証明つき準同型暗号とその対話的プロトコルMITSUNARI Shigeo
 
暗認本読書会13 advanced
暗認本読書会13 advanced暗認本読書会13 advanced
暗認本読書会13 advancedMITSUNARI Shigeo
 
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法MITSUNARI Shigeo
 
WebAssembly向け多倍長演算の実装
WebAssembly向け多倍長演算の実装WebAssembly向け多倍長演算の実装
WebAssembly向け多倍長演算の実装MITSUNARI Shigeo
 
Lifted-ElGamal暗号を用いた任意関数演算の二者間秘密計算プロトコルのmaliciousモデルにおける効率化
Lifted-ElGamal暗号を用いた任意関数演算の二者間秘密計算プロトコルのmaliciousモデルにおける効率化Lifted-ElGamal暗号を用いた任意関数演算の二者間秘密計算プロトコルのmaliciousモデルにおける効率化
Lifted-ElGamal暗号を用いた任意関数演算の二者間秘密計算プロトコルのmaliciousモデルにおける効率化MITSUNARI Shigeo
 
BLS署名の実装とその応用
BLS署名の実装とその応用BLS署名の実装とその応用
BLS署名の実装とその応用MITSUNARI Shigeo
 
LazyFP vulnerabilityの紹介
LazyFP vulnerabilityの紹介LazyFP vulnerabilityの紹介
LazyFP vulnerabilityの紹介MITSUNARI Shigeo
 

More from MITSUNARI Shigeo (20)

暗号技術の実装と数学
暗号技術の実装と数学暗号技術の実装と数学
暗号技術の実装と数学
 
範囲証明つき準同型暗号とその対話的プロトコル
範囲証明つき準同型暗号とその対話的プロトコル範囲証明つき準同型暗号とその対話的プロトコル
範囲証明つき準同型暗号とその対話的プロトコル
 
暗認本読書会13 advanced
暗認本読書会13 advanced暗認本読書会13 advanced
暗認本読書会13 advanced
 
暗認本読書会12
暗認本読書会12暗認本読書会12
暗認本読書会12
 
暗認本読書会11
暗認本読書会11暗認本読書会11
暗認本読書会11
 
暗認本読書会10
暗認本読書会10暗認本読書会10
暗認本読書会10
 
暗認本読書会9
暗認本読書会9暗認本読書会9
暗認本読書会9
 
暗認本読書会8
暗認本読書会8暗認本読書会8
暗認本読書会8
 
暗認本読書会7
暗認本読書会7暗認本読書会7
暗認本読書会7
 
暗認本読書会6
暗認本読書会6暗認本読書会6
暗認本読書会6
 
暗認本読書会5
暗認本読書会5暗認本読書会5
暗認本読書会5
 
暗認本読書会4
暗認本読書会4暗認本読書会4
暗認本読書会4
 
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
 
私とOSSの25年
私とOSSの25年私とOSSの25年
私とOSSの25年
 
WebAssembly向け多倍長演算の実装
WebAssembly向け多倍長演算の実装WebAssembly向け多倍長演算の実装
WebAssembly向け多倍長演算の実装
 
Lifted-ElGamal暗号を用いた任意関数演算の二者間秘密計算プロトコルのmaliciousモデルにおける効率化
Lifted-ElGamal暗号を用いた任意関数演算の二者間秘密計算プロトコルのmaliciousモデルにおける効率化Lifted-ElGamal暗号を用いた任意関数演算の二者間秘密計算プロトコルのmaliciousモデルにおける効率化
Lifted-ElGamal暗号を用いた任意関数演算の二者間秘密計算プロトコルのmaliciousモデルにおける効率化
 
楕円曲線と暗号
楕円曲線と暗号楕円曲線と暗号
楕円曲線と暗号
 
HPC Phys-20201203
HPC Phys-20201203HPC Phys-20201203
HPC Phys-20201203
 
BLS署名の実装とその応用
BLS署名の実装とその応用BLS署名の実装とその応用
BLS署名の実装とその応用
 
LazyFP vulnerabilityの紹介
LazyFP vulnerabilityの紹介LazyFP vulnerabilityの紹介
LazyFP vulnerabilityの紹介
 

ゆるバグ