kernel messages debug

[1265578519]

运行十年了头一次崩溃，异常原因，猜测是硬件问题？
opentracker[13006]: segfault at 7f6031449430 ip 0000000000405f3b sp 00007f60320b00f0 error 4 in opentracker[400000+14000]

[1265578519]

opentracker[23302]: segfault at 7f08c34dc430 ip 0000000000405f3b sp 00007f08c89b40f0 error 4 in opentracker[400000+14000]

[1265578519]

https://bbs.itzmx.com/forum.php?mod=redirect&goto=findpost&ptid=18214&pid=303135&fromuid=1
想起来，是以前改过这个，贴着8KB极限走的，udp大了就崩
要是还崩溃我就降低下数值得了
（发现设置50一样有这种情况，可能是核心代码bug问题）
[3086101.125185] opentracker[18869]: segfault at 7f25fd080010 ip 0000000000405ef3 sp 00007f2604ac30f0 error 4 in opentracker[400000+15000]
[3107613.076988] opentracker[22339]: segfault at 7f3ce3a6e210 ip 0000000000405ef3 sp 00007f3cf0c580f0 error 4 in opentracker[400000+15000]
[3145712.497406] opentracker[1404]: segfault at 7f59f971e8d0 ip 0000000000405f8b sp 00007f59fc4680f0 error 4 in opentracker[400000+15000]
[3188615.385459] opentracker[10673]: segfault at 7f8e1a2b0330 ip 0000000000405f8b sp 00007f8e1c74f0f0 error 4 in opentracker[400000+15000]
[3275337.146264] opentracker[26974]: segfault at 7fb568819230 ip 0000000000405ef3 sp 00007fb569e6e0f0 error 4 in opentracker[400000+15000]
[3436286.589852] opentracker[6507]: segfault at 7f2bcb7b1ef0 ip 0000000000405ef3 sp 00007f2bd0d550f0 error 4 in opentracker[400000+15000]
[3596379.775706] opentracker[9849]: segfault at 7f610cd9ad90 ip 0000000000405ef3 sp 00007f611e8200f0 error 4 in opentracker[400000+15000]
[3602918.272569] opentracker[12778]: segfault at 7f7222367450 ip 0000000000405f8b sp 00007f722389e0f0 error 4 in opentracker[400000+15000]

[1265578519]

[root@tracker ~]# dmesg | grep 'opentracker'
[4476559.117264] opentracker[24773]: segfault at 7fd0a21a8090 ip 0000000000405e4b sp 00007fd0a0db30f0 error 4 in opentracker[400000+15000]
[4498139.662202] opentracker[13312]: segfault at 7f93116fda50 ip 0000000000405db3 sp 00007f931253b0f0 error 4 in opentracker[400000+15000]
[4512390.632152] opentracker[27419]: segfault at 7f7be1eede10 ip 0000000000405db3 sp 00007f7be0b620f0 error 4 in opentracker[400000+15000]
[4518591.029451] opentracker[2603]: segfault at 7f8a6b1048b0 ip 0000000000405db3 sp 00007f8a69d660f0 error 4 in opentracker[400000+15000]
[4554770.392193] opentracker[9359]: segfault at 7fcf72d98f90 ip 0000000000405db3 sp 00007fcf719bf0f0 error 4 in opentracker[400000+15000]

错误信息基本只有软件作者才能看懂，或者作者自己也看不懂，c语言代码底层的问题，问作者 作者也没回，估计噶了

群友用IDA的结果

使用IDA F5后，大概发现是eax=0的时候没有到结尾 而是进入了数组循环 0在进入循环dex eax 把eax-到负数了 就会继续执行下去，int idx= amount -1，这个地方是idx=0时 跳到的 数组循环的结尾部分，idx初始化的时候 应该是0，应该判断小于0的时候 到结束 不能判断=0到结束 数组循环每次idx -1 在idx = amount -1上面 判断idx小于0 结束数组循环 到结尾 大概是这样

http://tracker1.itzmx.com:8080/stats?mode=top100
看起来是种子排行榜，要不然把这个页面禁掉试试？

编译后的二进制文件
opentracker.zip

崩溃前有个现象，stats页面卡住无响应，127.0.0.1访问都一直卡住没数据回应进不去，种子用户查询peer列表返回倒是正常，然后一段时间后就崩溃进程消失
感觉说不定就是这个top核心代码的问题

[1265578519]

gdb /home/OpenTracker-master/opentracker/opentracker 15914

(gdb) gcore
warning: target file /proc/15914/cmdline contained unexpected null characters
Saved corefile core.15914
(gdb) bt
#0  0x00007f876237dd23 in sendto () from /lib64/libpthread.so.0
#1  0x000000000040bed5 in ?? ()
#2  0x000000000040bf44 in ?? ()
#3  0x00000000004086a8 in ?? ()
#4  0x00000000004024a7 in ?? ()
#5  0x00007f8761dad555 in __libc_start_main () from /lib64/libc.so.6
#6  0x0000000000402a75 in ?? ()
(gdb) t 0
Thread ID 0 not known.
(gdb) bt
#0  0x00007f876237dd23 in sendto () from /lib64/libpthread.so.0
#1  0x000000000040bed5 in ?? ()
#2  0x000000000040bf44 in ?? ()
#3  0x00000000004086a8 in ?? ()
#4  0x00000000004024a7 in ?? ()
#5  0x00007f8761dad555 in __libc_start_main () from /lib64/libc.so.6
#6  0x0000000000402a75 in ?? ()
(gdb) t 1
[Switching to thread 1 (Thread 0x7f87627a2740 (LWP 15914))]
#0  0x00007f876237dd23 in sendto () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007f876237dd23 in sendto () from /lib64/libpthread.so.0
#1  0x000000000040bed5 in ?? ()
#2  0x000000000040bf44 in ?? ()
#3  0x00000000004086a8 in ?? ()
#4  0x00000000004024a7 in ?? ()
#5  0x00007f8761dad555 in __libc_start_main () from /lib64/libc.so.6
#6  0x0000000000402a75 in ?? ()
(gdb) t 2
[Switching to thread 2 (Thread 0x7f8761376700 (LWP 15916))]
#0  0x0000000000405c22 in ?? ()
(gdb) bt
#0  0x0000000000405c22 in ?? ()
#1  0x0000000000405fd7 in ?? ()
#2  0x00007f8762376ea5 in start_thread () from /lib64/libpthread.so.0
#3  0x00007f8761e89b0d in clone () from /lib64/libc.so.6
(gdb) t 3
[Switching to thread 3 (Thread 0x7f8761b77700 (LWP 15915))]
#0  0x00007f8761e509fd in nanosleep () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f8761e509fd in nanosleep () from /lib64/libc.so.6
#1  0x00007f8761e812d4 in usleep () from /lib64/libc.so.6
#2  0x0000000000407eaf in ?? ()
#3  0x00007f8762376ea5 in start_thread () from /lib64/libpthread.so.0
#4  0x00007f8761e89b0d in clone () from /lib64/libc.so.6
(gdb)

捕获的gdb文件，由于限制25MB，所以分卷成5个，记得改名删了后缀名解压
core_2.zip.001.zip
core_2.zip.002.zip
core_2.zip.003.zip
core_2.zip.004.zip
core_2.zip.005.zip

/lib64/libc.so.6
我寻思源代码里也没这个文件

gdb调试进程
00405c22~00405fd7内为空
上方的dmesg | grep 'opentracker'输出
00405e4b 和 00405db3就在这个范围内

把sprintf这几个nop怎么样，不过看起来是执行这个函数前的错误

ai说是打印之前的错误，错误在idx

[1265578519]

询问ai修复结果，不知道对不对，毕竟ai经常胡说八道

您的代码片段是一段C语言编写的Opentracker统计代码。要修复“空指针错误”，我们通常需要确定代码在哪些地方可能会遇到指针未预期赋值为NULL的情况，然后再确定如何处理。

首先，从stats_top_txt函数中修复您之前提出的循环条件问题，并添加适当的空指针检查：

1. 对于ot_vector *torrents_list可能为NULL需要检查。
2. 应该检查ot_torrent及其peer_list是否为NULL。

stats_top_txt函数中修复idx的循环：

for( bucket=0; bucket<OT_BUCKET_COUNT; ++bucket ) {
  ot_vector *torrents_list = mutex_bucket_lock( bucket );
  if (!torrents_list) {
    // 锁定bucket失败，处理错误或跳过该bucket
    continue;  
  }
  for( j=0; j<torrents_list->size; ++j ) {
    ot_peerlist *peer_list = ( ((ot_torrent*)(torrents_list->data))[j] ).peer_list;
    if (!peer_list) {
      // peer_list为空，处理错误或跳过该记录
      continue;
    }
    // 以下为原始代码，用于生成peer_count和seed_count的top列表
    // ...
  }
  mutex_bucket_unlock( bucket, 0 );
  if( !g_opentracker_running )
    return 0;
}

我们注意到函数mutex_bucket_lock的实现和外部变量OT_BUCKET_COUNT、g_opentracker_running没有在代码片段中给出定义。需要确保这些操作能正确处理NULL值。

在处理过程中，还有一点需要注意的是代码中对amount的操作。如果amount为0，以下代码：

int idx = amount - 1;
while( (idx >= 0) && ( /* condition */ ) ) --idx;
if ( idx++ != amount - 1 ) { /* ... */ }

有可能导致idx变为-1，此时对top100c[idx + 1]或top100s[idx + 1]的访问将超出数组界限。一定要保证在未定义行为发生之前，适当的检查已经完成。

最后，我提醒您，代码审查和测试是代码维护的重要环节，应该在实际部署之前，在多个层面上完成相应的检查。如果您还需要在其他函数中检查空指针或有其他问题，请继续提问。

[1265578519]

群友发了个修复代码，他说：只改了这里，因为是iovec_increase函数返回的Null引起崩溃，而且stats_shift_down_network_count函数中的free函数在释放以后也没重置为Null会导致内存泄漏

/* 
原代码
static void stats_make( int *iovec_entries, struct iovec **iovector, ot_tasktype mode ) {
  char *r;

  *iovec_entries = 0;
  *iovector      = NULL;
  if( !( r = iovec_increase( iovec_entries, iovector, OT_STATS_TMPSIZE ) ) )
    return;

  switch( mode & TASK_TASK_MASK ) {
    case TASK_STATS_TORRENTS:    r += stats_torrents_mrtg( r );             break;
    case TASK_STATS_PEERS:       r += stats_peers_mrtg( r );                break;
    case TASK_STATS_SLASH24S:    r += stats_slash24s_txt( r, 128 );         break;
    case TASK_STATS_TOP10:       r += stats_top_txt( r, 10 );               break;
    case TASK_STATS_TOP100:
                                 r = iovec_fix_increase_or_free( iovec_entries, iovector, r, 4 * OT_STATS_TMPSIZE );
                                 if( !r ) return;
                                 r += stats_top_txt( r, 100 );              break;
    case TASK_STATS_EVERYTHING:  r += stats_return_everything( r );         break;
#ifdef WANT_SPOT_WOODPECKER
    case TASK_STATS_WOODPECKERS: r += stats_return_woodpeckers( r, 128 );   break;
#endif
#ifdef WANT_FULLLOG_NETWORKS
    case TASK_STATS_FULLLOG:      stats_return_fulllog( iovec_entries, iovector, r );
                                                                            return;
#endif
    default:
      iovec_free(iovec_entries, iovector);
      return;
  }
  iovec_fixlast( iovec_entries, iovector, r );
}
*/ 

/* 新代码修复stats界面空指针 */
static void stats_make(int *iovec_entries, struct iovec **iovector, ot_tasktype mode) {
    char *r;

    *iovec_entries = 0;
    *iovector = NULL;
    if (!(r = iovec_increase(iovec_entries, iovector, OT_STATS_TMPSIZE))) {
        // 内存分配失败,释放之前可能已分配的iovector内存并返回
        iovec_free(iovec_entries, iovector);
        return;
    }

    switch (mode & TASK_TASK_MASK) {
        case TASK_STATS_TORRENTS:
            r += stats_torrents_mrtg(r);
            break;
        case TASK_STATS_PEERS:
            r += stats_peers_mrtg(r);
            break;
        case TASK_STATS_SLASH24S:
            r += stats_slash24s_txt(r, 128);
            break;
        case TASK_STATS_TOP10:
            r += stats_top_txt(r, 10);
            break;
        case TASK_STATS_TOP100:
            r = iovec_fix_increase_or_free(iovec_entries, iovector, r, 4 * OT_STATS_TMPSIZE);
            if (!r) {
                // 内存重新分配失败的话,释放之前可能已分配的iovector内存并返回
                iovec_free(iovec_entries, iovector);
                return;
            }
            r += stats_top_txt(r, 100);
            break;
        case TASK_STATS_EVERYTHING:
            r += stats_return_everything(r);
            break;
#ifdef WANT_SPOT_WOODPECKER
        case TASK_STATS_WOODPECKERS:
            r += stats_return_woodpeckers(r, 128);
            break;
#endif
#ifdef WANT_FULLLOG_NETWORKS
        case TASK_STATS_FULLLOG:
            stats_return_fulllog(iovec_entries, iovector, r);
            // 无需返回,stats_return_fulllog 已经解决了释放内存
            return;
#endif
        default:
            // 处理未知类型,释放内存并返回
            iovec_free(iovec_entries, iovector);
            return;
    }
    iovec_fixlast(iovec_entries, iovector, r);
}
/* 新代码结束 */

实测这位群友发的修复代码没有用，还是出现崩溃现象，我感觉ai说的没错，应该是idx的问题，这位群友不知道修到哪去了

[erdgeist]

Hey,

I am the author of opentracker and am looking into the bug.

This fix here is not necessary:

            if (!r) {
                // 内存重新分配失败的话,释放之前可能已分配的iovector内存并返回
                iovec_free(iovec_entries, iovector);
                return;
            }

because iovec_fix_increase_or_free already frees the memory if reallocation fails.

Also idx in #4 (comment) can never be 0, because the function stats_top_text will only be called from stats_make with amount either 10 or 100.

In order to see where the problem is, could you please execute opentracker.debug inside a gdb or lldb?

If the crash occurs, please attach a backtrace of the functions.

[1265578519]

@erdgeist 我使用gdb的操作方法是否正确？
我在stats页面即将卡死的时候捕获了gcore文件（此时进程还没崩溃，我是否要等待到发生崩溃？）

[root@tracker ~]# cd /home/OpenTracker-master/opentracker
[root@tracker opentracker]# gdb --args ./opentracker.debug -f opentracker.conf.sample -p 81 -P 8080 -p 6961 -P 6961 -p 2710 -P 2710
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/OpenTracker-master/opentracker/opentracker.debug...done.
(gdb) run
Starting program: /home/OpenTracker-master/opentracker/./opentracker.debug -f opentracker.conf.sample -p 81 -P 8080 -p 6961 -P 6961 -p 2710 -P 2710
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Binding socket type TCP to address [::]:81... success.
Binding socket type UDP to address [::]:8080... success.
Binding socket type TCP to address [::]:6961... success.
Binding socket type UDP to address [::]:6961... success.
Binding socket type TCP to address [::]:2710... success.
Binding socket type UDP to address [::]:2710... success.
Dropping to user nobody.
[New Thread 0x7ffff73c7700 (LWP 13267)]
[New Thread 0x7ffff6bc6700 (LWP 13268)]
 installing 0 workers on udp socket -1

bt
^C
Program received signal SIGINT, Interrupt.
0x00007ffff76da0e3 in epoll_wait () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.x86_64 zlib-1.2.7-21.el7_9.x86_64
(gdb) bt
#0  0x00007ffff76da0e3 in epoll_wait () from /lib64/libc.so.6
#1  0x000000000040e368 in io_waituntil2 ()
#2  0x000000000040287a in server_mainloop (args=0x0) at opentracker.c:294
#3  0x0000000000403c42 in main (argc=15, argv=0x7fffffffe4a8) at opentracker.c:693
(gdb) t 0
Thread ID 0 not known.
(gdb) bt
#0  0x00007ffff76da0e3 in epoll_wait () from /lib64/libc.so.6
#1  0x000000000040e368 in io_waituntil2 ()
#2  0x000000000040287a in server_mainloop (args=0x0) at opentracker.c:294
#3  0x0000000000403c42 in main (argc=15, argv=0x7fffffffe4a8) at opentracker.c:693
(gdb) t 1
[Switching to thread 1 (Thread 0x7ffff7fed740 (LWP 13263))]
#0  0x00007ffff76da0e3 in epoll_wait () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff76da0e3 in epoll_wait () from /lib64/libc.so.6
#1  0x000000000040e368 in io_waituntil2 ()
#2  0x000000000040287a in server_mainloop (args=0x0) at opentracker.c:294
#3  0x0000000000403c42 in main (argc=15, argv=0x7fffffffe4a8) at opentracker.c:693
(gdb) t 2
[Switching to thread 2 (Thread 0x7ffff73c7700 (LWP 13267))]
#0  0x00007ffff76a09fd in nanosleep () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff76a09fd in nanosleep () from /lib64/libc.so.6
#1  0x00007ffff76d12d4 in usleep () from /lib64/libc.so.6
#2  0x0000000000408ce6 in clean_worker (args=0x0) at ot_clean.c:123
#3  0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#4  0x00007ffff76d9b0d in clone () from /lib64/libc.so.6
(gdb) t 3
[Switching to thread 3 (Thread 0x7ffff6bc6700 (LWP 13268))]
#0  0x00000000004064c3 in stats_top_txt (reply=0x7ffff0005e30 "\330\a", amount=100) at ot_stats.c:315
315	      int idx = amount - 1; while( (idx >= 0) && ( peer_list->peer_count > top100c[idx].val ) ) --idx;
(gdb) bt
#0  0x00000000004064c3 in stats_top_txt (reply=0x7ffff0005e30 "\330\a", amount=100) at ot_stats.c:315
#1  0x0000000000407705 in stats_make (iovec_entries=0x7ffff6bc5f04, iovector=0x7ffff6bc5ef8, 
    mode=TASK_STATS_TOP100) at ot_stats.c:620
#2  0x0000000000407b2b in stats_worker (args=0x0) at ot_stats.c:752
#3  0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#4  0x00007ffff76d9b0d in clone () from /lib64/libc.so.6
(gdb) t 4
Thread ID 4 not known.
(gdb) gcore
warning: target file /proc/13263/cmdline contained unexpected null characters
Saved corefile core.13263
(gdb) quit
A debugging session is active.

	Inferior 1 [process 13263] will be killed.

Quit anyway? (y or n) y
[root@tracker opentracker]#

opentracker.debug二进制文件和gcore文件，由于限制25MB，所以分卷成3个，记得改名删了后缀名解压

core.13263.zip.001.zip
core.13263.zip.002.zip
core.13263.zip.003.zip

[1265578519]

正在等待进程崩溃，明天我将更新崩溃后的gcore文件到issues

[1265578519]

崩溃比预想来得更快，稍后编辑并且上传zip文件

[root@tracker opentracker]# gdb --args ./opentracker.debug -f opentracker.conf.sample -p 81 -P 8080 -p 6961 -P 6961 -p 2710 -P 2710
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/OpenTracker-master/opentracker/opentracker.debug...done.
(gdb) run
Starting program: /home/OpenTracker-master/opentracker/./opentracker.debug -f opentracker.conf.sample -p 81 -P 8080 -p 6961 -P 6961 -p 2710 -P 2710
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Binding socket type TCP to address [::]:81... success.
Binding socket type UDP to address [::]:8080... success.
Binding socket type TCP to address [::]:6961... success.
Binding socket type UDP to address [::]:6961... success.
Binding socket type TCP to address [::]:2710... success.
Binding socket type UDP to address [::]:2710... success.
Dropping to user nobody.
[New Thread 0x7ffff73c7700 (LWP 22282)]
[New Thread 0x7ffff6bc6700 (LWP 22283)]
 installing 0 workers on udp socket -1

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff6bc6700 (LWP 22283)]
0x00000000004063a8 in to_hex (
    d=0x7ffff6bc51b1 "FB704F7612DB2F172433969A1CA054C95C61C84", 
    s=0x7ffff7ef6410 <Address 0x7ffff7ef6410 out of bounds>) at ot_stats.c:294
294	static char*to_hex(char*d,uint8_t*s){char*m="0123456789ABCDEF";char *t=d;char*e=d+40;while(d<e){*d++=m[*s>>4];*d++=m[*s++&15];}*d=0;return t;}
Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.x86_64 zlib-1.2.7-21.el7_9.x86_64
(gdb) gcore
warning: target file /proc/22278/cmdline contained unexpected null characters
Saved corefile core.22278
(gdb) 

除了这个崩溃问题，我认为还需要解决stats的还有
1.增加一个超时，我不明白为什么会卡住五分钟服务器才响应结果，他应该60秒无响应504并且断开用户连接
2.为什么访问没有任何参数的stats，响应了top的页面？

opentracker.debug二进制文件和gcore文件，由于限制25MB，所以分卷成5个，记得改名删了后缀名解压

core.22278.zip.001.zip
core.22278.zip.002.zip
core.22278.zip.003.zip
core.22278.zip.004.zip
core.22278.zip.005.zip

刚刚发现崩溃太兴奋，忘记执行bt命令了，补上

[root@tracker ~]# gdb /home/OpenTracker-master/opentracker/opentracker.debug core*
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/OpenTracker-master/opentracker/opentracker.debug...done.

warning: core file may not match specified executable file.
[New LWP 22283]
[New LWP 22282]
[New LWP 22278]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/home/OpenTracker-master/opentracker/./opentracker.debug -f opentracker.conf.sam'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000004063a8 in to_hex (d=0x7ffff6bc51b1 "FB704F7612DB2F172433969A1CA054C95C61C84", s=0x7ffff7ef6410 <Address 0x7ffff7ef6410 out of bounds>) at ot_stats.c:294
294	static char*to_hex(char*d,uint8_t*s){char*m="0123456789ABCDEF";char *t=d;char*e=d+40;while(d<e){*d++=m[*s>>4];*d++=m[*s++&15];}*d=0;return t;}
Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.x86_64 zlib-1.2.7-21.el7_9.x86_64
(gdb) bt
#0  0x00000000004063a8 in to_hex (d=0x7ffff6bc51b1 "FB704F7612DB2F172433969A1CA054C95C61C84", s=0x7ffff7ef6410 <Address 0x7ffff7ef6410 out of bounds>) at ot_stats.c:294
#1  0x00000000004067e7 in stats_top_txt (
    reply=0x7ffff0021e00 "Top 100 torrents by peers:\n\t1243\tDE0066558293DC30E80C77AF657431A0C81F27BA\n\t1093\t0E10E2430B1888C20408BB6C4A9E577A227BFFD5\n\t1088\t7CDBAA3CF35B4A6EC194220B09D4373AC02CAF1B\n\t1027\tF14D81DC3C78642CF760534AD9"..., amount=100) at ot_stats.c:340
#2  0x0000000000407705 in stats_make (iovec_entries=0x7ffff6bc5f04, iovector=0x7ffff6bc5ef8, mode=TASK_STATS_TOP100) at ot_stats.c:620
#3  0x0000000000407b2b in stats_worker (args=0x0) at ot_stats.c:752
#4  0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#5  0x00007ffff76d9b0d in clone () from /lib64/libc.so.6
(gdb) t 2
[Switching to thread 2 (Thread 0x7ffff73c7700 (LWP 22282))]
#0  0x00007ffff76a09fd in nanosleep () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff76a09fd in nanosleep () from /lib64/libc.so.6
#1  0x00007ffff76d12d4 in usleep () from /lib64/libc.so.6
#2  0x0000000000408ce6 in clean_worker (args=0x0) at ot_clean.c:123
#3  0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#4  0x00007ffff76d9b0d in clone () from /lib64/libc.so.6
(gdb) t 3
[Switching to thread 3 (Thread 0x7ffff7fed740 (LWP 22278))]
#0  0x0000000000405830 in mutex_workqueue_popresult (iovec_entries=0x7fffffffc2c4, iovec=0x7fffffffc2c8) at ot_mutex.c:241
241	  while( *task && ( (*task)->tasktype != TASK_DONE ) )
(gdb) bt
#0  0x0000000000405830 in mutex_workqueue_popresult (iovec_entries=0x7fffffffc2c4, iovec=0x7fffffffc2c8) at ot_mutex.c:241
#1  0x0000000000402959 in server_mainloop (args=0x0) at opentracker.c:308
#2  0x0000000000403c42 in main (argc=15, argv=0x7fffffffe4a8) at opentracker.c:693
(gdb) 

为什么访问没有任何参数的stats，响应了top的页面？

可能就是因为这个问题，，导致了崩溃
输出了其它的内存数据

[erdgeist]

I identified a potential issue and fixed that in https://erdgeist.org/gitweb/opentracker/commit/?id=9c98e1e775c48684442fe97ca93bfa71b295d81e

I do not know how to merge from upstream master branch into this repository. But maybe you check it out.

[1265578519]

@erdgeist 更新代码了，这个bug还在，，，等会看看崩不崩溃吧
不带参数访问可能卡出BUG输出top的内容

多次F5刷新就复现
http://49.12.76.8:2710/stats
我有预感，因为stats页面卡住，就是即将出现进程崩溃的前兆

如果发生崩溃我将补充gdb，目前更新后还没崩
就是CPU占用奇高，stats界面卡死，估计代码死循环了
估计stats有bug，导致CPU高了也有点影响announce

[1265578519]

好消息是今天没有崩溃，坏消息是stats页面卡死
由于stats页面卡死导致进程CPU升高，引起announce一起响应变慢
卡死的时候gdb一下

Program received signal SIGINT, Interrupt.
0x0000000000405825 in mutex_workqueue_popresult (iovec_entries=0x7fffffffc2c4, iovec=0x7fffffffc2c8) at ot_mutex.c:241
241    while( *task && ( (*task)->tasktype != TASK_DONE ) )
Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.x86_64 zlib-1.2.7-21.el7_9.x86_64
(gdb) bt
#0  0x0000000000405825 in mutex_workqueue_popresult (iovec_entries=0x7fffffffc2c4, iovec=0x7fffffffc2c8) at ot_mutex.c:241
#1  0x0000000000402967 in server_mainloop (args=0x0) at opentracker.c:311
#2  0x0000000000403c4b in main (argc=15, argv=0x7fffffffe4a8) at opentracker.c:702
(gdb) t 2
[Switching to thread 2 (Thread 0x7ffff73c7700 (LWP 31958))]
b#0  0x00007ffff76a09fd in nanosleep () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff76a09fd in nanosleep () from /lib64/libc.so.6
#1  0x00007ffff76d12d4 in usleep () from /lib64/libc.so.6
#2  0x0000000000408cef in clean_worker (args=0x0) at ot_clean.c:124
#3  0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#4  0x00007ffff76d9b0d in clone () from /lib64/libc.so.6
(gdb) t 3
[Switching to thread 3 (Thread 0x7ffff6bc6700 (LWP 31959))]
#0  0x00007ffff7bcd54d in __lll_lock_wait () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007ffff7bcd54d in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007ffff7bc8e9b in _L_lock_883 () from /lib64/libpthread.so.0
#2  0x00007ffff7bc8d68 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000000000405744 in mutex_workqueue_pushresult (taskid=89113, iovec_entries=2, iovec=0x7ffff00d4d20) at ot_mutex.c:207
#4  0x0000000000407b49 in stats_worker (args=0x0) at ot_stats.c:757
#5  0x00007ffff7bc6ea5 in start_thread () from /lib64/libpthread.so.0
#6  0x00007ffff76d9b0d in clone () from /lib64/libc.so.6
(gdb)

是不是这里问题，好像每次输出都不一样

#4  0x0000000000407b49 in stats_worker (args=0x0) at ot_stats.c:757

看起来要用更专业的profiler来分析CPU占用问题了

问了下ai的回复

这段代码在一个死循环中不断处理任务，并且没有可见的延迟或睡眠调用，这可能是导致高CPU占用的主要原因。在没有任务要处理时，这个线程将会不断轮询，导致它在每一次迭代中都尝试去获取任务，并且这个操作是CPU密集型的。

当这个线程被唤醒来处理新任务时，这是正常的；然而，在没有任务时，它应该等待，而不是在一个紧凑的循环中占用CPU资源。

要解决这个问题，可以考虑以下几个可能的方案：

1. 使用条件变量：修改 mutex_workqueue_poptask() 函数，使其在任务队列为空时休眠线程，并在新任务到达时唤醒线程。这通常通过条件变量和互斥锁实现。

2. 添加延迟或睡眠：如果条件变量不可用或不希望修改队列的实现，可以在循环中添加一个延迟(sleep, usleep, nanosleep)。这不是一个理想的解决方案，因为它引入了人为的延迟，可能会影响到任务处理的实时性。

3. 使用事件驱动的设计：使用事件循环库（如libevent或libuv）来处理任务队列，只有在队列中实际有任务要处理时才唤醒线程。

4. 使用消息队列：使用系统级的消息队列（如POSIX的消息队列），这些队列已经提供了阻塞线程直到消息到达的机制。

5. 改进互斥和同步原语：如果mutex_workqueue_poptask使用的是自旋锁或者其他忙等待机制进行同步，换成阻塞式的同步原语可以减少CPU占用。

6. 利用现有的并发库：很多编程环境有成熟的并发库可以处理这类问题，如C++的线程库、Java的ExecutorService等。

具体采取哪种方案取决于现有代码的其他部分和程序需要符合的特定要求。通常情况下，让一个工作线程在没有工作可做时进入休眠是解决此类问题最好的方法。

ida里面看到会发生死循环的，所以死循环还是卡死stats，但是修复了崩溃？
估计是因为这个死循环，导致没有参数的stats输出了top的内容