注意：如果您的问题是安全问题，请发送电子邮件至 [email protected] 而不是公开问题 1. 请说英语，这是所有维护者都可以说和写的语言。 2. 请在我们的 Discord 服务器（https://discord.gg/gitea）或论坛（https://discourse.gitea.io）上提问或配置/部署问题。 3. 请花点时间检查您的问题是否已经存在。 4. 错误报告请在下方提供所有相关信息，因为不完整的详细信息将作为无效报告处理。
- Gitea 版本（或提交参考）：1.12.0+dev-440-gf5a20250a
Git 版本：git 版本 2.20.1
操作系统：Raspbian GNU/Linux 10 (buster) on Raspberry Pi zero w
- 数据库（使用
[x]）：- [] PostgreSQL
- [x] MySQL
- [ ] MSSQL
- [] SQLite
- 您能否在https://try.gitea.io重现该错误：
- [ ] 是（提供示例 URL）
- [x] 否
- [ ] 不相关
- 日志要点：
- 架构：linux-arm-6
描述
将gitea升级到这个版本后，发现gitea运行很慢。
通过查看CPU使用率，CPU使用率保持100%。
我检查了 ps，发现似乎gitea hook进程（2395、964）正在占用大量资源，我想知道它们是什么以及如何跟踪它们以及如何阻止它们。
据我所知，我的 repo 中没有 git hook 设置在这个服务器上运行。 所以我认为这可能是 gitea 的系统钩子。
我看到 PID 2366 说duchenpaul/homebridge-docker.git正在执行钩子，但是在那个 repo 中没有设置钩子脚本
作为PID 961，我不知道那里发生了什么。
我查看了日志，只有日志中查询的sql，没有错误
928 ? Ss 0:00 \_ sshd: git [priv]
937 ? S 0:00 | \_ sshd: git<strong i="5">@notty</strong>
939 ? Rsl 14:49 | \_ /home/git/gitea/gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
987 ? Ss 0:00 \_ sshd: git [priv]
996 ? S 0:00 | \_ sshd: git<strong i="6">@notty</strong>
998 ? Rsl 12:43 | \_ /home/git/gitea/gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
1310 ? Ss 0:00 \_ sshd: git [priv]
1319 ? S 0:00 | \_ sshd: git<strong i="7">@notty</strong>
1321 ? Rsl 10:04 | \_ /home/git/gitea/gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
2062 ? Ss 0:00 \_ sshd: pi [priv]
2071 ? S 0:02 | \_ sshd: pi@pts/1
2074 pts/1 Ss 0:00 | \_ -bash
2482 pts/1 S+ 0:00 | \_ vi gitea.log
2349 ? Ss 0:00 \_ sshd: git [priv]
2358 ? S 0:00 \_ sshd: git<strong i="8">@notty</strong>
2360 ? Ssl 0:03 \_ /home/git/gitea/gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
2366 ? Sl 0:00 \_ git-receive-pack duchenpaul/homebridge-docker.git
2390 ? S 0:00 \_ bash hooks/post-receive
2394 ? S 0:00 \_ bash ./hooks/post-receive.d/gitea
2395 ? Rl 4:55 \_ /home/git/gitea/gitea hook --config=/home/git/gitea/custom/conf/app.ini post-receive
454 tty1 Ss+ 0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
525 ? Ss 0:00 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
619 ? S 0:00 \_ php-fpm: pool www
620 ? S 0:00 \_ php-fpm: pool www
586 ? Ss 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
590 ? S 0:00 \_ nginx: worker process
654 ? Ss 0:00 /lib/systemd/systemd --user
680 ? S 0:00 \_ (sd-pam)
700 ? Ss 0:00 /lib/systemd/systemd --user
723 ? S 0:00 \_ (sd-pam)
753 ? Ss 0:00 /usr/sbin/exim4 -bd -q30m
961 ? S 0:00 bash hooks/update refs/heads/master 2b1fb9ae3617e7fc0b9b496897b542e1e3e24375 9a610f1bb0fdd659a4fa5ef7576ff3dc27690f22
963 ? S 0:00 \_ bash ./hooks/update.d/gitea refs/heads/master 2b1fb9ae3617e7fc0b9b496897b542e1e3e24375 9a610f1bb0fdd659a4fa5ef7576ff3dc27690f22
964 ? Rl 14:45 \_ /home/git/gitea/gitea hook --config=/home/git/gitea/custom/conf/app.ini update refs/heads/master 2b1fb9ae3617e7fc0b9b496897b542e1e3e24375 9a610f1bb0fdd659a4fa5ef7576ff3dc27690f22
2175 ? Ssl 1:49 /home/git/gitea/gitea web
[更新] 总结
gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini的挂起是从git客户端的请求中引入的，由于某些原因，一些git请求没有正确完成，而是占用了所有的CPU几个小时并减慢了系统。- 而且这些进程与gitea主服务无关，即使我停止了gitea服务，这些进程仍然挂在那里。
- 看起来bug是从版本中的v1.11.2（0768823）开始的，我用的是v1.11.1（ff24f81），没关系，但是只要我切换到v1.11.2，上面的事情就会在短时间内开始发生.
截图
duchenpaul
所有53条评论
另外，我观察到有 3 个名为gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini进程占用了大部分 CPU，它们是什么？ 怎么可能阻止
duchenpaul
于 2020-03-08
这三个进程（939、998 和 1321）听起来像是 git 客户端的服务器端。 他们都有key-3的事实意味着他们都使用相同的凭据（公钥）。 可能是您尝试推送，然后取消，但由于某种原因，服务器端还没有意识到这一点。
但罪魁祸首似乎是：
964 ? Rl 14:45 \_ /home/git/gitea/gitea hook --config=/home/git/gitea/custom/conf/app.ini update refs/heads/master 2b1fb9ae3617e7fc0b9b496897b542e1e3e24375 9a610f1bb0fdd659a4fa5ef7576ff3dc27690f22
这是 Gitea 在存储库上的更新挂钩。 14:45值是使用的累积 CPU 时间，这不正常，除非您在旧 Pentium 计算机上推送 Linux 内核源代码。
是的，这些钩子是 Gitea 的 git 管道，可以让事情在幕后工作。
一些想法：
- 尝试重新启动。 严重地。 如果由于某种偶然原因某些进程挂在您身上，但它仍在锁定某些文件，这将杀死它。
- 尝试通过管理菜单在 repo 上执行
git fsck和git gc。 它可能有问题。
此外，Raspberry Pi Zero W 中没有太多 RAM。 尝试检查您的系统是否分页过多。 使用top程序并点击m键，直到内存图出现：
或者也许vmstat 3 999 （你用CTRL+C取消它）：
si和so列在大多数情况下应该是 0。 分页进出是真正减慢系统速度的事情。
（注意：不要像您的系统那样使用我图片中的值：我的是一个 CentOS 7 虚拟机，分配了 12GB 的 RAM）。
guillep2k
于 2020-03-08
谢谢你的回复，
我又重新启动了，现在看起来没问题。
我在战斗中没有取消任何交易，从我看到的客户端来看，所有交易都正常完成。
我相信我所指的 PID 964 由于 ssh 事务的 CPU 使用率高而被阻止
我的问题是：
- 是否有超时设置取消了服务器端的 ssh 事务，这需要太多时间？
- 有没有办法追踪那些 ssh 交易的情况。
无论如何，我会持续监测3天，如果可以，我会关闭这个问题。
这个gitea服务器只为我自己服务，我认为它仍然能够很好地处理这项工作。 😄
vmstat 3 999
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 4036 68112 28512 141908 0 5 523 45 576 1210 17 9 72 2 0
0 0 4036 68112 28512 141908 0 0 0 0 434 877 4 3 93 0 0
0 0 4036 68112 28512 141908 0 0 0 0 405 856 6 1 93 0 0
1 0 4036 68112 28512 141908 0 0 0 0 454 917 4 2 94 0 0
3 0 4036 68112 28512 141908 0 0 0 0 532 1086 7 2 91 0 0
[更新] 我发现这两个 gitea serv 进程再次弹出，而我什至没有做任何事情。
谁能帮我查一下是谁造成的？
pi<strong i="9">@Venus</strong> ~ $ vmstat 3 999
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
4 0 16172 84076 11680 106668 0 1 42 5 548 996 84 3 13 0 0
3 0 16172 84076 11680 106668 0 0 0 0 554 958 99 1 0 0 0
3 0 16172 84076 11680 106668 0 0 0 0 582 1027 96 4 0 0 0
4 0 16172 84076 11680 106668 0 0 0 0 704 1296 98 2 0 0 0
3 0 16172 84076 11680 106668 0 0 0 0 561 1015 97 3 0 0 0
4 0 16172 84076 11680 106668 0 0 0 0 648 1170 97 3 0 0 0
暂时关闭，我发现这可能是我的 github 桌面导致的。 我改用 GitExtensions，它永远不会挂起。
duchenpaul
于 2020-03-08
一些 git 工具可能会在后台检查 repo 状态。
lunny
于 2020-03-08
是的，从github桌面的日志可以看出，但是怎么会在服务器端进程卡住，占用所有cpu资源，甚至客户端退出，客户端PC断电。
duchenpaul
于 2020-03-08
不确定 - 我们需要从 gitea 中查看一些关于它在做什么的日志。
例如update钩子应该基本上是空的 - 我建议它完全删除，因为它只会减慢速度。
zeripath
于 2020-03-08
是的，我会重新打开这个问题，并将我的 gitea 日志级别设置为 debug 以收集更多信息。
我没有在任何 repo 中使用update钩子。 只有post-receive几个仓库中的一个只是为了在远程服务器上部署代码。
现在我发现即使 gitea dump 有时也会停顿，只是挂在那里并使 CPU 全速运转。
duchenpaul
于 2020-03-09
这是我用于调试的日志配置：
[log]
MODE = file
LEVEL = Debug
ROOT_PATH = /home/git/gitea/log
REDIRECT_MACARON_LOG = true
STACKTRACE_LEVEL = Debug
ENABLE_ACCESS_LOG = true
ENABLE_XORM_LOG = true
XORM = ,
有什么可以添加的东西来帮助定位问题吗？
duchenpaul
于 2020-03-09
又停顿了。
PID 8480 占用 100% 的 CPU 使用率。 连gitea服务都被我拦住了。
8469 ? Ss 0:00 \_ sshd: git [priv]
8478 ? S 0:00 | \_ sshd: git<strong i="7">@notty</strong>
8480 ? Rsl 5:04 | \_ /home/git/gitea/gitea --config=/home/git/gitea/custom/conf/app.ini serv key-6
8486 ? Ss 0:00 \_ sshd: pi [priv]
8495 ? S 0:00 \_ sshd: pi@pts/3
8498 pts/3 Ss 0:00 \_ -bash
8637 pts/3 R+ 0:00 \_ ps xfa
452 tty1 Ss+ 0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
568 ? Ss 0:08 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
653 ? S 0:00 \_ php-fpm: pool www
656 ? S 0:00 \_ php-fpm: pool www
633 ? Ss 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
637 ? S 0:00 \_ nginx: worker process
725 ? Ss 0:00 /usr/sbin/exim4 -bd -q30m
7762 ? Ss 0:00 /lib/systemd/systemd --user
7766 ? S 0:00 \_ (sd-pam)
8334 ? Ss 0:00 /lib/systemd/systemd --user
8337 ? S 0:00 \_ (sd-pam)
[ 09:52 - 192.168.31.150 ]
pi<strong i="8">@Venus</strong> ~ $ ps -o lstart -o etime -p 8480
STARTED ELAPSED
Mon Mar 9 09:46:14 2020 05:59
[ 09:52 - 192.168.31.150 ]
pi<strong i="9">@Venus</strong> ~ $
这个过程从 09:46:14 开始，我检查了那个时候的每个日志，我发现只有Started Session c187 of user git. ，我的 git 客户端正在尝试在后台更新 repo
附上我可以在下面找到的日志。
duchenpaul
于 2020-03-09
你试过运行 fsck 和 gc 吗？ 考虑到您使用 SD 卡来存储存储库，这些很重要。 如果您无法通过 Gitea 执行此操作（例如系统在您有机会之前被锁定），您可以 _shutdown Gitea_ 并自己运行命令：
cd /home/git/gitea-repositories
( for user in * ; do cd "$user" ; echo "--- USER: $user ---"
for repo in * ; do cd $repo ; echo "--- REPO: $repo ---"
git fsck && git gc || exit
cd .. ; done ; cd .. ; done )
（如果需要，相应地更改初始路径）
guillep2k
于 2020-03-09
注意： STACKTRACE_LEVEL = Debug是多余的。 您应该将其更改为Error这样重要的消息就不会在日志中隐藏得太深。
guillep2k
于 2020-03-09
是的，我确实尝试过 fsck 和 gc，谢谢你的 bash 片段，它就像一个魅力，并且完美地结束。
我猜在 arch linux-arm-6 上的 1.11.0+dev-481-g1df701fd1(good) 和 1.10.5+18-gd6657644a(bad) 之间引入了一些错误。
我刚刚格式化了 SD 卡，以排除我的文件系统问题，并使用我几天前备份的映像进行恢复，使用 gitea 版本： 1.11.0+dev-481-g1df701fd1 。
保持运行数小时，执行一些推拉动作。 没关系。
我将 gitea 升级到主版本1.10.5+18-gd6657644a ，问题重现。 现在我回滚到以前的版本，看看我的假设是否正确。
duchenpaul
于 2020-03-09
更新
似乎我们在标记最新的master图像时遇到了一些问题； 它是1.12.0+dev但版本字符串显示1.10.5 。 😳
原始消息（以防万一它有用）
但是......那些不是真正的发布，你实际上是_降级。_🤔发布的版本号只有三位数字，之后没有其他数字。
我们的最新版本是1.11.2 。 如果您想要 _cutting edge_（即我们目前正在开发但尚未完善的版本），您可以选择master 。 如果你想从源代码构建，你需要 _exactly_ v1.11.2 （或master ）。
master版本是1.12.0+dev-something ，例如1.12.0+dev-435-g6a57364dc表示“在1.12.0+dev标签建立后 435 次提交”，即在我们开始工作后 435 次提交在 1.12。
1.10.5是我们针对 1.10 分支的最新补丁版本，我们仍在维护它以解决严重的错误。
guillep2k
于 2020-03-09
是的，我注意到版本号有问题。 但我确定新版本有问题。
我从这里的主文件夹下载 gitea： https://dl.gitea.io/gitea/master/gitea-master-linux-arm-6 ，这是最新版本，也是发生这种事情的地方。
duchenpaul
于 2020-03-09
升级到 Gitea 版本：1.11.2 (0768823)，来自 github 版本，问题仍然存在。
我将逐个版本降级以缩小问题范围
duchenpaul
于 2020-03-09
看起来错误在这 2 个提交之间：ff24f81 - 0768823。
我正在运行 v1.11.1(ff24f81)，到目前为止一切顺利
duchenpaul
于 2020-03-09
您确定运行的是 MySQL 而不是 Sqlite？
zeripath
于 2020-03-09
MySQL：版本：mysql Ver 15.1 Distrib 10.3.22-MariaDB，用于 debian-linux-gnueabihf (armv8l) 使用 readline 5.2
我不认为这与数据库有关。
gitea 服务器无法处理来自客户端的某些请求，这些进程如下所示，只是在那里处理几个小时，占用了所有的 CPU。
我想知道是否有日志来跟踪这种行为？ 有趣的是，这只发生在 github v1.11.x 版本中的 v1.11.2 上。 一定是哪里有问题。
gitea serv key-3 --config=/home/git/gitea/custom/conf/app.ini
堆栈跟踪没有帮助 - 一旦我们确定了问题，它们对于弄清楚为什么会导致问题更有用。 话虽如此，为了快速查看，从日志中删除它们并不太难。
我已经查看了您的 daemon.log，我看不到任何对 Gitea 的请求是打开而不关闭的，这些请求最多大约一秒钟。
我现在正在看其他人。
zeripath
于 2020-03-09
你有挂起时的任何日志吗？
zeripath
于 2020-03-09
这些是我在挂起时捕获的日志
duchenpaul
于 2020-03-09
我不知道这是否合适，但如果你愿意，我可以给你 ssh 访问我的服务器，只是为了帮助解决问题。
我的电子邮件： [email protected]
duchenpaul
于 2020-03-09
运行grep git auth.log | grep sshd:session仅显示几个超过 2 分钟的会话：
"sshd[1969]:" 23.0
"sshd[2114]:" 7.0
"sshd[5028]:" 83.0
"sshd[5363]:" 25.0
"sshd[5574]:" 8.0
"sshd[6406]:" 12.0
sshd[5028] 是：
Mar 8 20:57:53 venus sshd[5028]: Accepted publickey for git from 61.155.3.10 port 6063 ssh2: RSA SHA256:
Mar 8 20:57:53 venus sshd[5028]: pam_unix(sshd:session): session opened for user git by (uid=0)
...
Mar 8 22:21:26 venus sshd[5028]: pam_unix(sshd:session): session closed for user git
但是我看不到当时发生了什么，因为没有日志。
zeripath
于 2020-03-09
换个思路，我把处理挂的细节贴上去。 这个过程开始于 3 月 9 日 09:46:14 及以下是我从身份验证日志中提取的内容，我相信这是挂起的会话，它没有停止，因为我手动杀死了它或只是重新启动服务器。
Mar 9 09:46:14 venus sshd[8469]: Accepted publickey for git from 192.168.2.1 port 50681 ssh2: RSA SHA256:rV+R5HyRUMVvl4taCsKmkY0IMhq7Rg0437wWScz6U1o
Mar 9 09:46:14 venus sshd[8469]: pam_unix(sshd:session): session opened for user git by (uid=0)
Mar 9 09:46:14 venus systemd-logind[253]: New session c187 of user git.
如果你想查看日志，只要看到时间戳“Mar 9 09:46:14”这是中国时间，UTC+8小时，Gitea日志是UTC时间，你应该做一个转换
duchenpaul
于 2020-03-09
但是我在 daemon.log 中找不到未完成的帖子或访问 gitea ...
zeripath
于 2020-03-09
你当然找不到。 我总结一下问题：
进程的挂起是由客户端的 git 请求引入的。
我的 git 客户端是 github 桌面，它定期执行 git fetch 并且它的一些请求只是挂在那里。
也许我应该发布 github 桌面日志。
duchenpaul
于 2020-03-10
我在问题报告评论（第一条评论）中更新了我过去几天收集的一些信息
duchenpaul
于 2020-03-10
将 gitea 更新到 1.11.2 后，我遇到了同样的问题。 我的系统是 Linux amd64，我使用 sqlite。
jedy
于 2020-03-10
一个进程在问题信息上调用/home/git/gitea/gitea hook --config=/home/git/gitea/custom/conf/app.ini post-receive 。
@jedy如果您退出所有 git 客户端，然后升级到 v1.11.2，它们还会发生吗？
lunny
于 2020-03-10
我只能建议从这些进程之一创建核心转储。 我们至少可以看到它在做什么。 问题是没有办法清理核心转储，所以你不应该分享它的原始内容。
如果您已经安装了 delve 或 gdb，也许您可以打开那些内核并告诉我们它们在做什么。
guillep2k
于 2020-03-10
好的，我会还给你的。
duchenpaul
于 2020-03-10
我用 go 1.13.8 编译了 1.11.2。 现在看来可以了。
jedy
于 2020-03-10
@jedy如果可能的话，你
duchenpaul
于 2020-03-10
@duchenpaul对不起。 我没有arm环境。在linux上交叉编译有一些错误。
jedy
于 2020-03-10
挂起过程的gdb回溯：
[root<strong i="6">@s60</strong> git]# gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p 24006
0x000000000045b4e8 in runtime.step (p=..., pc=0xc000009828, val=0xc000009824, first=false, newp=..., ok=true) at /usr/local/go/src/runtime/symtab.go:867
867 /usr/local/go/src/runtime/symtab.go: No such file or directory.
warning: Missing auto-load scripts referenced in section .debug_gdb_scripts
of file /var/git/gitea
Use `info auto-load python [REGEXP]' to list them.
Thread 1 (process 24006):
#0 0x000000000045b4e8 in runtime.step (p=..., pc=0xc000009828, val=0xc000009824, first=false, newp=..., ok=true) at /usr/local/go/src/runtime/symtab.go:867
#1 0x000000000045a785 in runtime.pcvalue (f=..., off=11692510, targetpc=22398159, cache=0x0, strict=true, ~r5=<optimized out>) at /usr/local/go/src/runtime/symtab.go:687
#2 0x000000000045b276 in runtime.pcdatavalue (f=..., table=0, targetpc=22398159, cache=0x0, ~r4=<optimized out>) at /usr/local/go/src/runtime/symtab.go:822
#3 0x000000000043d17f in runtime.isAsyncSafePoint (gp=0xc000000180, pc=22398159, sp=824645152416, lr=<optimized out>, ~r4=<optimized out>) at /usr/local/go/src/runtime/preempt.go:396
#4 0x0000000000451858 in runtime.doSigPreempt (gp=0xc000000180, ctxt=0xc0000099d0) at /usr/local/go/src/runtime/signal_unix.go:329
#5 0x0000000000452429 in runtime.sighandler (sig=23, info=0xc000009bf0, ctxt=0xc000009ac0, gp=0xc000000180) at /usr/local/go/src/runtime/signal_unix.go:536
#6 0x0000000000451a49 in runtime.sigtrampgo (sig=23, info=0xc000009bf0, ctx=0xc000009ac0) at /usr/local/go/src/runtime/signal_unix.go:444
#7 0x00000000004707f3 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_amd64.s:389
#8 <signal handler called>
#9 0x000000000155c4cf in code.gitea.io/gitea/modules/public.glob..func1 (~r0=...) at /go/src/code.gitea.io/gitea/modules/public/bindata.go:14786
#10 0x0000000001565b52 in code.gitea.io/gitea/modules/public.init () at /go/src/code.gitea.io/gitea/modules/public/bindata.go:14787
#11 0x000000000044b0ea in runtime.doInit (t=0x42de880 <code.gitea.io/gitea/modules/public..inittask>) at /usr/local/go/src/runtime/stubs.go:12
#12 0x000000000044b0b7 in runtime.doInit (t=0x42ebb40 <code.gitea.io/gitea/routers/routes..inittask>) at /usr/local/go/src/runtime/proc.go:5409
#13 0x000000000044b0b7 in runtime.doInit (t=0x42edd00 <code.gitea.io/gitea/cmd..inittask>) at /usr/local/go/src/runtime/proc.go:5409
#14 0x000000000044b0b7 in runtime.doInit (t=0x42dd460 <main..inittask>) at /usr/local/go/src/runtime/proc.go:5409
#15 0x000000000043e4ce in runtime.main () at /usr/local/go/src/runtime/proc.go:190
#16 0x000000000046e8f1 in runtime.goexit () at /usr/local/go/src/runtime/asm_amd64.s:1373
#17 0x0000000000000000 in ?? ()
我在挂起过程中运行了 strace。 出现了很多 SIGURG。 我认为这可能与使用 SIGURG 的 Go 的新抢占式运行时有关。 所以我尝试了 1.13.8。 经过一个小时的良好运行，我认为这就是问题所在。
jedy
于 2020-03-10
我在挂起过程中运行了 strace。 出现了很多 SIGURG。 我认为这可能与使用 SIGURG 的 Go 的新抢占式运行时有关。 所以我尝试了 1.13.8。 经过一个小时的良好运行，我认为这就是问题所在。
不错的收获！ 我们需要仔细研究这一点。
guillep2k
于 2020-03-10
回溯仅显示第一个线程，这可能不是最有用的。 🙁
guillep2k
于 2020-03-10
10684 可能会修复此问题，它将在 v1.11.3 上发布
lunny
于 2020-03-10
我的 go 版本是Go1.13.8 ，准确吗？
duchenpaul
于 2020-03-10
这是我的 gdb 转储，对此有何想法？
git<strong i="6">@Venus</strong> ~ $ gdb -ex "set pagination 0" -ex "thread apply all bt" --batch -p 2327
[New LWP 2328]
[New LWP 2329]
[New LWP 2330]
[New LWP 2331]
0x00065868 in runtime.step (p=..., pc=0x4409b50, val=0x4409b4c, first=false, newp=..., ok=true) at /usr/local/go/src/runtime/symtab.go:867
867 /usr/local/go/src/runtime/symtab.go: No such file or directory.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/git/gitea/gitea.
Use `info auto-load python-scripts [REGEXP]' to list them.
Thread 5 (LWP 2331):
#0 runtime.futex () at /usr/local/go/src/runtime/sys_linux_arm.s:415
#1 0x00042568 in runtime.futexsleep (addr=0x411b8c4 <runtime.newmHandoff+12>, val=0, ns=-1) at /usr/local/go/src/runtime/os_linux.go:44
#2 0x0001a404 in runtime.notesleep (n=0x411b8c4 <runtime.newmHandoff+12>) at /usr/local/go/src/runtime/lock_futex.go:151
#3 0x0004c298 in runtime.templateThread () at /usr/local/go/src/runtime/proc.go:1806
#4 0x0004ad6c in runtime.mstart1 () at /usr/local/go/src/runtime/proc.go:1097
#5 0x0004aca8 in runtime.mstart () at /usr/local/go/src/runtime/proc.go:1062
#6 0x014ca07c in crosscall_arm1 () at gcc_arm.S:30
#7 0x014c9dc4 in threadentry ()
#8 0x014cb5a8 in start_thread (arg=0xa51ff2f0) at pthread_create.c:463
#9 0x014ff4c8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 4 (LWP 2330):
#0 runtime.futex () at /usr/local/go/src/runtime/sys_linux_arm.s:415
#1 0x00042568 in runtime.futexsleep (addr=0x445066c, val=0, ns=-1) at /usr/local/go/src/runtime/os_linux.go:44
#2 0x0001a404 in runtime.notesleep (n=0x445066c) at /usr/local/go/src/runtime/lock_futex.go:151
#3 0x0004c378 in runtime.stopm () at /usr/local/go/src/runtime/proc.go:1828
#4 0x0004cb88 in runtime.startlockedm (gp=0x44000e0) at /usr/local/go/src/runtime/proc.go:2001
#5 0x0004e290 in runtime.schedule () at /usr/local/go/src/runtime/proc.go:2557
#6 0x0004ee14 in runtime.goschedImpl (gp=0x4400700) at /usr/local/go/src/runtime/proc.go:2705
#7 0x0004ee9c in runtime.gosched_m (gp=0x4400700) at /usr/local/go/src/runtime/proc.go:2713
#8 0x0007671c in runtime.mcall () at /usr/local/go/src/runtime/asm_arm.s:285
#9 0x0444dfc8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 3 (LWP 2329):
#0 runtime.futex () at /usr/local/go/src/runtime/sys_linux_arm.s:415
#1 0x00042568 in runtime.futexsleep (addr=0x445048c, val=0, ns=-1) at /usr/local/go/src/runtime/os_linux.go:44
#2 0x0001a404 in runtime.notesleep (n=0x445048c) at /usr/local/go/src/runtime/lock_futex.go:151
#3 0x0004c378 in runtime.stopm () at /usr/local/go/src/runtime/proc.go:1828
#4 0x0004cb88 in runtime.startlockedm (gp=0x44000e0) at /usr/local/go/src/runtime/proc.go:2001
#5 0x0004e290 in runtime.schedule () at /usr/local/go/src/runtime/proc.go:2557
#6 0x0004ebf8 in runtime.park_m (gp=0x44007e0) at /usr/local/go/src/runtime/proc.go:2690
#7 0x0007671c in runtime.mcall () at /usr/local/go/src/runtime/asm_arm.s:285
#8 0x0444de00 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 2 (LWP 2328):
#0 runtime.usleep () at /usr/local/go/src/runtime/sys_linux_arm.s:575
#1 0x000531f8 in runtime.sysmon () at /usr/local/go/src/runtime/proc.go:4473
#2 0x0004ad6c in runtime.mstart1 () at /usr/local/go/src/runtime/proc.go:1097
#3 0x0004aca8 in runtime.mstart () at /usr/local/go/src/runtime/proc.go:1062
#4 0x014ca07c in crosscall_arm1 () at gcc_arm.S:30
#5 0x014c9dc4 in threadentry ()
#6 0x014cb5a8 in start_thread (arg=0xa6d2c2f0) at pthread_create.c:463
#7 0x014ff4c8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (LWP 2327):
#0 0x00065868 in runtime.step (p=..., pc=0x4409b50, val=0x4409b4c, first=false, newp=..., ok=true) at /usr/local/go/src/runtime/symtab.go:867
#1 0x00064d68 in runtime.pcvalue (f=..., off=7823431, targetpc=12885908, cache=0x0, strict=true, ~r5=<optimized out>) at /usr/local/go/src/runtime/symtab.go:687
#2 0x00065704 in runtime.pcdatavalue (f=..., table=0, targetpc=12885908, cache=0x0, ~r4=<optimized out>) at /usr/local/go/src/runtime/symtab.go:822
#3 0x000471e4 in runtime.isAsyncSafePoint (gp=0x44000e0, pc=12885908, sp=86869636, lr=<optimized out>, ~r4=<optimized out>) at /usr/local/go/src/runtime/preempt.go:396
#4 0x0005c9e0 in runtime.doSigPreempt (gp=0x44000e0, ctxt=0x4409c1c) at /usr/local/go/src/runtime/signal_unix.go:329
#5 0x0005d5d0 in runtime.sighandler (sig=23, info=0x4409c90, ctxt=0x4409d10, gp=0x44000e0) at /usr/local/go/src/runtime/signal_unix.go:536
#6 0x0005cc6c in runtime.sigtrampgo (sig=23, info=0x4409c90, ctx=0x4409d10) at /usr/local/go/src/runtime/signal_unix.go:444
#7 0x00079728 in runtime.sigtramp () at /usr/local/go/src/runtime/sys_linux_arm.s:534
#8 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Inferior 1 (process 2327) detached]
[ 19:07 - 192.168.31.150 ]
git<strong i="7">@Venus</strong> ~ $
更新到 1.11.2 后我遇到了同样的问题
我正在使用 sqlite 并在 Fedora Server 30 x64 下运行
如果有人需要有关此的更多信息，我可以提供。
joaodforce
于 2020-03-10
1.11.3几分钟后就出来了。 请尝试一下，让我们知道您的结果。 （确保在升级前没有 Gitea 进程仍然处于活动状态）。
guillep2k
于 2020-03-11
到目前为止看起来不错，但是我们丢失了代码语言栏？
曾经有一个指标显示该项目中语言的百分比。
duchenpaul
于 2020-03-11
语言统计仅在 1.12+ 版本（1.12 是当前未发布的主分支）
jolheiser
于 2020-03-11
好的，但在 1.11.2 中发现，看起来它是固定的！ 点赞！！
duchenpaul
于 2020-03-11
我不确定这实际上是否已修复——如果使用 go 1.13 进行编译修复了它，那么使用 go 1.14 继续使用 master 和新版本应该仍然存在相同的问题
mrsdizzie
于 2020-03-11
是的@mrsdizzie我们需要弄清楚是什么导致了这种情况。 go 发布文档对于如何解决这个问题不是很清楚。
zeripath
于 2020-03-11
@zeripath @mrsdizzie如果您需要我的任何助手，请告诉我
duchenpaul
于 2020-03-13
相关问题
ghost
·
3评论
Fastidious
·
3评论
adpande
·
3评论
BRMateus2
·
3评论
cookiengineer
·
3评论