视频播放结束时，偶现程序崩溃问题

[tiansongyu]

我遇到的程序崩溃场景都是在系统播放开始和结束时，没有遇到过播放过程中突然崩溃的情况，我猜测会不会是播放结束后，资源的释放和播放开始时资源的申请有问题

[xfangfang]

这种情况应该只在switch上发生，我有尝试在进入视频播放页的时候不播放视频，这种情况下随意操作切换页面都不会发生报错，所以这个问题应该还是和mpv或者和ffmpeg相关的

[xfangfang]

更新一下我的进度：

方向1:

查阅mpv的文档时候发现了一段内容：

• mpv may start sub processes, so overriding SIGCHLD, or waiting on all PIDs (such as calling wait()) by the parent process or any other library within the process must be avoided. libmpv itself only waits for its own PIDs.
• If anything in the process registers signal handlers, they must set the SA_RESTART flag. Otherwise you WILL get random failures on signals.

注意到官方搭配SDL使用MPV的时候，有这么一句：

SDL_SetHint(SDL_HINT_NO_SIGNAL_HANDLERS, "no");

由于wiliwili使用的是glfw，很难说有没有其他的坑，尤其是这个glfw是移植的，仓库标注了WIP，很可能本身就存在问题。所以一个尝试的方向是使用SDL绘制视频页面。

方向2:

尝试使用GDB无果，好像大气层这个GDB更多是用来做金手指的，没有（或者我没找到）有效的办法加载符号表，呈现出来的信息非常有限。

方向3:

尝试使用：aarch64-none-elf-addr2line 搭配系统报错报告找到错误的位置（/atmosphere/crash_reports/）。
（下面的两次尝试都是在播放同一直播视频时候发生的，流程是点击某个直播画面还没加载出来之前就卡住）

指令：aarch64-none-elf-addr2line -e /Users/fang/Desktop/xfang/wiliwili/cmake-build-switch/wiliwili.elf -f -p -C -a 0x13230f0
最后的地址替换为 Stack Trace 后面的地址

0x000000000126822c: _EntryWrap at :?
0x00000000012799f8: __thread_entry at :?
0x000000000067f0c0: open_demux_thread at :?
0x00000000006bed08: demux_open_url at :?
0x00000000006be650: open_given_type at :?
0x0000000001098e20: av_dict_set at :?
0x00000000013230f0: _realloc_r at :? <----- 错误发生在这之后

0x000000000126822c: _EntryWrap at :?
0x00000000012799f8: __thread_entry at :?
0x000000000066f944: core_thread at :?
0x00000000006836ac: mp_play_files at :?
0x0000000000682748: play_current_file at :?
0x000000000068b62c: init_video_decoder at :?
0x00000000006d5dfc: mp_decoder_wrapper_create at :?
0x00000000006dbac0: mp_filter_add_pin at :?
0x00000000006a6c38: ta_alloc_size at :? <----- 错误发生在这之后

我找了一下共同点：

1. 出问题的位置貌似都和申请内存有关
2. 系统报错代码都是 (2168-0002)，这个报错代码和直接从相册打开软件播放视频的报错代码一致

可能的解决方法是：

1. 因为switch是共用显存内存的，如果超频能解决问题，会不会是超频的时候某些内存分配会有变化，这方面还得研究一下。
2. 在libnx代码中找找可用的配置选项，一般来说是在代码中搜索：__attribute__((weak))
3. 限制mpv的内存使用，这方面我没什么思路，因为之前已经限制了缓存在几百兆内，感觉应该不会是简单的内存不足。
4. 因为applet和application模式在播放视频时候报错代码是一致的，所以可以从这两个模式的区别入手

---

补充一次崩溃记录，这次是正常播放视频，在退出时候发生的

0x000000000126822c: _EntryWrap at :?
0x00000000012799f8: __thread_entry at :?
0x00000000006bdc18: demux_thread at :?
0x00000000006bc7ac: thread_work at :?
0x00000000008bff54: ffurl_closep at :?
0x000000000131d1d8: _free_r at :?

共同点1修改为：在子线程中申请或释放内存

[xfangfang]

补充推测：

早期的wiliwili存在内存泄露，这个时候会经常出现报错，使用exfat内存卡尤为突出。

虽然不清楚内存泄露与报错的联系，但是使用内存检测工具查看，貌似mpv或者ffmpeg的部分还是存在内存泄露，作为可能性之一罗列在此。

解决办法或许是尽可能换一个新版本的mpv搭配ffmpeg测试。

[tiansongyu]

内存

建议 ns编译mpv 和ffmpeg的版本补充一下，使用哪些版本 ，我编译 ns ffmpeg还是遇到了依赖库缺少的问题，或者整一个 docker

[xfangfang]

建议 ns编译mpv 和ffmpeg的版本补充一下，使用哪些版本 ，我编译 ns ffmpeg还是遇到了依赖库缺少的问题，或者整一个 docker

我想在解决了播放器问题之后再去做docker。

ffmpeg和mpv的版本参考nxmp项目就可以了，readme中有提及。（nxmp也提供了编译好的内容）

我认为，mpv最新 搭配 ffmpeg4.4最新 应该也是可以的。

如果是依赖库缺少，感觉应该是编译配置的问题，这个可以发出来报错大家一起看看

[xfangfang]

一个有趣的解决方式，更换了一下直播接口，把直播视频格式从hls改为了flv，不会出错了。

---

顺带一提，貌似线程 detach在switch上是不能使用的，我在switch-examples仓库的issue中有看到相关的讨论。

---

附上我现在使用的ffmpeg和mpv：
wiliwili_ffmpeg_mpv.zip

[tiansongyu]

用了你的ffmpeg Lib库编译的可以打开视频了，但是现在最新的版本switch好像打不开，我回退到0629bcf16072c3d8cc0ab45747040dd9bb6617b2 switch版本开启后黑屏，回退到2d80dd600d4d10b6bb231994a45eaf19eb0f211a可以打开了，问题应该 2d80dd6 和 0629bcf 之间 ，黑屏应该不是我代码造成的

另外我试过确实不能用thread detach ，detach 后软件会crash 我改天换个写法

[tiansongyu]

DeskTop版本没有问题

[xfangfang]

这个问题我也发现了，临时的解决方法是：

1. main函数开启debug log：brls::Logger::setLogLevel(brls::LogLevel::LOG_DEBUG);
2. 或者：在main函数 brls::Application::init() 前用error log随便输出一句话

看了一下报错应该是初始化手柄振动时候报的错，应该是这段时间清理了一些没有用的log导致这个问题暴露出来了（而且我在mac上编译一直也没遇到，刚刚换到linux才复现的）

至于为什么log会影响到初始化手柄，我正在看，真是什么离奇的bug都有

[xfangfang]

应该是解决了，可以拉下代码试一试。

应该是手柄振动部分变量声明有问题，在某些情况下（比如多加一条log），恰好内存对齐了就没事（我猜的）。

[xfangfang]

非常惊讶地发现这个问题解决了，之前一直是mpv报错，结果没想到是ffmpeg在switch上的一个补丁导致的问题，支持了docker构建，新的构建方式可以看更新的readme。