mzhan017的博客

gdb调试这个size的值都被优化掉了。如果不知道这个值，我们就需要根据coredump的内容来倒推。是不是说如果出现这个错误，就一定代表是堆内存被损坏了？那损坏的原因要怎么看？比如这一段里，明显可以将size的大小打印到printerr里。

通过gdb可以看到redhat提供的是打开了这个选项。

需要注意，如果函数和main函数是再一个编译单元，不会trigger这个warning。需要变成成单独的o/so文件，在链接时才会报错。

gethostbyname3_context 这里的使用是如果设置的inet6，就优先做AAAA的query，如果失败，而且res_use_inet6设置了，就会尝试ip4的Aquery。但是有赖于/etc/resolv.conf options: inet6 的设置。默认，如果设置的hint是AF_UNSPEC，而且没有额外的noaaaa的设置的时候，会ip4和ip6同时retrieve。如果设置为AF_INET6，就只会发 AAAA的query。

在 C 语言中，检查文件是否存在可以使用标准库函数，例如 fopen、access、或 stat。access 函数可以检查文件的可访问性。如果文件存在且可读，返回 0，否则返回 -1。总结：这三种方法都可以有效地检查文件是否存在。stat 函数可以获取文件的状态信息，如果文件存在返回 0，否则返回 -1。使用 fopen 打开文件，如果返回的指针不是 NULL，则表示文件存在。access: 更加高效，仅检查文件的存在性和可访问性。stat: 获取文件详细信息的同时检查文件存在性。

最终发现，是因为系统里的interface/ip配置的量太大，而arping命令会使用这个getifaddrs这个接口函数。这里可以看到是arping这个命令，里的getifaddrs_internal，会占用这个cpu。这里也看到perf没有抓到详细的backtrace路径。

gettimeofday实际在/sys/time.h文件里。这里的sys的含义更多的是和系统的实现相关，不是标准。

英文单词context这里是上下文的意思，那对于应用程序在跑的过程种，有哪些信息属于上下文呢？根据内核的代码来看有，程序执行时的寄存器内容/内存的内容。可以使用接口函数getcontext，来获取这个上下文信息。是内核组装的一个上下文结构体，在用户层可以访问。以下为intel x86-64为例。

glibc-2.28/sysdeps/unix/sysv/linux/syscalls.list文件里的定义，也说是映射到系统调用syslog。所以不要纠结说，为什么在glibc里找不到相应的klogctl.c这么个文件。在Linux系统里有这个系统调用的定义在printk.c这个文件里。从Linux的源码里才能查看到103是什么。

应该是为了阅读代码的方便性，因为如果不加空格会对代码阅读造成一定的困难；但是为什么不直接将整个#define都缩进呢？应个人的阅读爱好，其实只要养成一种阅读习惯，就可以，不管是前加空格还是后加空格，只要可用表示出if缩进块的功能就好。在这一篇中有提到，井号与define之间空格，可能导致搜索上的一些问题。

今天找到了这个GL的定义，记录一下，费了一些劲才找到的。（没有想到的是#和define之间还有空格，导致一直搜不到想要的结果。）是在sysdeps/generic/ldsodefs.h文件中。依赖于SHARED和rtld的定义。所以这个的定义就是一个全局结构体里的一个成员。

这个结构体的定义是基本相同，除了linux/if.h里在最后多了一个结构体变量（16个字节）。也就是最终传递给linux内核的内容，内核还是可以匹配，只要不使用多出来的这个变量。上面这个编译错误最终是被解决了，就是怎么放这两个文件都没有问题，顺序无关，order-free。这两个头文件，如果已经存在net/if.h话，后续linux/if.h 里的某些定义会失效。最近看到一段代码改动，用net/if.h替换了linux/if.h。那唯一的好处是，如果是堆上存放这个类型变量，占用的内存小。

从glibc的内部看，返回给系统的途径，要根据申请的方式来判断，比如根据实现，使用sbrk/brk申请的内存，要用sbrk/brk来返回给操作系统。如果系统内存不够用，可能会导致新的程序例的内存申请返回errno=12，申请不到内存。意思是说，当释放的内存（和前后可以整合的chunk之和）大小超过了这个值，就会走入整合的逻辑，在整合之后根据heap里的top空闲内存的大小（和M_TRIM_THRESHOLD作比较）来判断释放要做trim。举例：假如一个程序，申请的都是小内存，连续申请2G。

标准输入输出，所对应的file descriptor，是0、1、2，如果想将其他的文件描述符对应到这几个上，也需要使用dup。然后这样对于这个线程来说，这个标准输入与输出就映射到其他的文件描述符，方便实现相关功能，管道，socket pair，线程间通信。都不知道为什么这个dup来，dup去的，有啥意思？比如下面的操作，第一步，用openat打开一个只读的文件，第二步lseek，第三步，用读写打开，再dup。因为这个dup的行为，就是为文件的操作，多设置几个文件描述符，看似没有什么太大的用途。

从这里看，这个strlcpy、strlcat的引入glibc的过程还是很慢长。为什么一直没有放进来？其实还是很方便使用。Kernel里的版本；

但是POSIX.1，允许实现的自由，不管是返回一个数值，还是一个结构体，都是允许的，只要可以唯一表示一个线程。The pthread_self() function returns the ID of the calling thread. 这个值和pthread_create返回的值是一个值。从glibc的实现，就x86来说是，使用了寄存器fs，访问了tls的数据，pthread.header.self变量。返回值就是pthread_t值，永远不会失败。上面这个结论在使用说明里有明确的说明;

从 daemon-7里可以看到，这个方法会将之前的线程直接exit_group(0)。这样在判断返回值时其实不是真正的线程的状态。在daemon之前创建的子线程，在主线程执行daemon之后会有不同的getpgid。因为会重新设置setsid。将当前进程运行到后台，脱离当前session、shell。也就是会设置thread的pgid。

在include/features.h 里有下面的定义，也就是说；__USE_MISC代表着使用之前4.3 BSD或者System V unix系统设计的一些代码。需要在_DEFAULT_SOURCE定义的情况下才会有__USE_MISC；相关介绍：https://mzhan017.blog.csdn.net/article/details/122441412；当然这个链接里说的是应用层的_DEFAULT_SOURCE的定义。而这篇的主要目的是对glibc编译使用的_DEFAULT_SOURCE；1。

chatGPT给出的答案，如果使用的是Linux操作系统，就使用linux/un.h下的文件。如果是其他系统，就是要sys/un.h。这里可能要从特有性来分析了，chatGPT说的没有错误。但是如果软件是兼容多个系统的时候，就需要考虑sys目录下的un.h。所以还是建议使用glibc下的un.h 文件。但是在使用的时候，选择哪一个呢？

ChatGPT 使用经历

这里列的两个接口是一对，在上面手册里有说，如果不再需要attr对象，需要使用pthread_attr_destroy，来销毁这个对象。但是如果不详细看，其实看不出来为什么一定要成对使用。这个extension是谁申请内存的呢？搜索glibc的代码会发现，下面这个函数有申请内存给extension。然后上面这个接口的使用手册也是没有提destroy的事情。所以还是有机会出现内存泄漏。所以如果在init和destroy不成对使用时，会有内存泄漏的风险。明显是调用了free释放内存。

从上面的使用说明上看，在调用pthread_cond_wait之前，需要确保，mutex已经lock了。如果调用这个函数的时候，不能确定mutex已经lock。可能会出现未定义的行为。潜在会留下一些问题，但是不一定什么时候出现，这就为问题调试埋下了隐患。

这个性能改进的的出发点是。如果可以将pid缓存在当前应用程序的用户空间，就可以避免用户内核空间的交换。会提高一些性能，只是纯碎的做性能提升。但是当将缓存的代码放到正式glibc库之后，因为改动的代码比较基础，后续发现了一些解决不了的问题，最后这个缓存的功能去掉了。当然这种性能的改进方法可以放到用户层，这样就可以避免动基础的代码，但是缺点就是需要没改应用一份代码，代码重复。其实就这个例子来说，是有很多东西可以总结，比如：做优化不是做了就完了，而且需要做大量的，全面的测试。这个函数就会讲pid缓存在应用层。

有一个全局变量 FILE *fileP;在一个线程使用的时候，另一个做了close操作，导致 _IO_write_ptr为0，然后出现coredump。

/* This macro indicates that the installed library is the GNU C Library. For historic reasons the value now is 6 and this will stay from now on. The use of this variable is deprecated. Use __GLIBC__ and __GLIBC_MINOR__ now (see below) when you w

【代码】glibc: 这个函数是平台定制__syscall_sigreturn；如x86可能就返回 ENOSYS。

这个下面的内容其实很早就有了，一般不这么用。但是知道这个之后，或许可以使用一下，因为程序实际跑的时候，会调用到__init_misc函数。其实就是一个指针，帮我们指向了argv[0]的地址。这段代码的历史很早了，也许_init_misc可以做更多的事情。} }

如果glibc的模块编译含有这个MODULE_NAME；就会生成相关的宏定义；

do_notify_parent函数里有判断，如果父进程的信号处理对于SIGCHLD的action是IGN，系统会自动回收退出的进程。无需父进程执行wait函数。在进程最终的exit函数里，会将进程的状态置为Exit_zombie的状态。无需考虑这个问题，因为system函数里有调用wait。

在计算机中，这个arena的含义，特指通过brk/sbrk挂载到进程的内存区域，被malloc使用的动态存储空间。Latin harena, arena sand, sandy place，从拉丁语进化来的单词，原意有多沙的地方，沙地。一般在沙地上比武，然后进化成角斗场，舞台。尿沉渣，有沙子的外观，所以叫尿沙。也只是类比，如沙子的形状。一块内存区域，非常若干可用块，类沙，被malloc使用。上面这句的意思就是，在可用块链表里检测到不可能值的时候，报的一个“corrupt arena”：破损内存区。

glibc: fgets 使用规范，返回值一定要判断；

ksoftirq与pthread_cond_wait之间的联系

glibc/kernel，mprotect

glibc -DSHARED

prctl 使用

pclose coredump

pthread_create在设置attr->sched_priority时，要注意是否超过limit

atomic与call_once的选择

glibc 编译相关

System 函数会调用到 wait4 系统调用kernel/exit.c/wait4 ->kernel_wait4->