- 博客(161)
- 资源 (22)
- 收藏
- 关注
原创 glibc中xdr的一个bug
本人是64位的gcc编译器,long类型是8个字节,所能表示的数字范围远远大于4294967295。本人在64位linux服务器上(centos7),发现xdr_u_long这个函数有个bug,就是数字的范围如果超过unsigned int的最大值(4294967295)时,xdr_u_long失败。经过测试,xdr_u_long所能编码的最大值为4294967295,此时间戳对应的时间大概是2106年。而uint64_t和u_long的类型是一致的,都是unsigned long int。
2024-10-26 15:11:10 415
原创 c++中引用是通过指针的方式实现
可以看到,红色方框圈里来的有两部分,其中第一部分是栈帧大小的圈定,bp是栈底,sp是栈顶,由于栈是自顶向下生长,所以sp其实比bp小。红色部分的3部分,第一部分是栈帧大小的开辟,第二部分是栈帧数据的初始化,第三部分是首先将x的值赋给eax,然后将0Ah,即数字10,赋给eax所指的内存单元,即x所指的内存单元。第一步,lea eax,[a]是指将a的地址赋给eax,第二部push eax,这步是参数压栈,而eax目前的值是a的地址,故压栈的参数就是a的地址。然后按F11,进入到fuzhi函数的汇编代码处。
2024-09-17 11:48:21 386
原创 关于setrlimit RLIMIT_STACK的一点说明
main函数栈帧的限制在编译的时候就确定了,是8M。故main函数中设置的栈大小为1M,在后面的函数print中生效。而print函数中定义了2M大小的栈变量szBuf,在main函数真正调用print时,会先进行栈限制检查。下面代码,设置栈大小为1024字节,然后后面又定义了2 * 1024的数组,并在print也定义了2 * 1024的数组,但是程序并没有崩溃。可以看到进程崩溃了,但是可以看其打印,print打印出来的,这说明崩溃的时候,是在进入print崩溃的。不是在main函数里面崩溃的。
2024-09-16 17:40:25 317
原创 fork出的子进程,调用exec函数后,其信号处理函数会被继承吗
首先需要说明的是,exec后,子进程和父进程属于不同的代码段。信号处理函数不会被继承,但是某些针对信号的设置,还是可以传递的,比如exec前,设置信号处理为SIG_IGN,则exec后,该信号依然保持SIG_IGN属性。该程序名叫做forktest3,终端上运行./forktest3 &;放入后台运行,可以看到后台有两个进程:forktest3和sleep 1000。设置后,尽管后面调用了exec,但是该信号设置依然有效。然后关闭掉终端,可以发现forktest3消失了,但是sleep 1000还在。
2024-08-15 17:12:13 147
原创 linux 父进程退出时,激活了子进程的情况说明
针对第二种情况,为何子进程会退出,这里做简单说明,杀掉父进程后,子进程会接收到SIGHUP信号,而此信号,子进程没有处理,则默认结束子进程;此时暂停子进程,然后杀掉父进程,则子进程被激活,并且不会退出。今天在此记录一下几种情况。
2024-08-14 20:28:21 222
原创 文件描述符中设置FD_CLOEXEC的用处
linux中,父进程fork出子进程,子进程本身会继承父进程的所有文件描述符。若子进程再调用exec系列函数转化为新的进程实体,其实父进程的描述符对其没有意义。此时文件上只需要设置FD_CLOEXEC即可。注意,如果fork进程后,没有调用exec,则无论FD_CLOEXEC是否设置,子进程一定会继承父进程的全部文件描述符。再运行看看情况,如下所示,产生的两个进程号分别是64187,64188,可以看到文件描述符被子进程继承了。然后查看进程的fd信息,可以看到my.txt这个文件描述符没有继承下去。
2024-08-08 18:49:47 268
原创 linux父进程fork出子进程后,子进程为何首先需要close文件描述符。
考虑到一种情况,父进程创建了tcp服务端套接字,并且listen,此时fork出子进程,若子进程里面不close此监听套接字,则子进程里面是否能接收到客户端的连接。答案是可以的,现在构造一个服务端程序,listen后,fork出子进程,然后父进程进入sleep,子进程调用accept,在accept成功后,打印对应的信息。在linux c/c++编程时,父进程fork出子进程后,子进程经常第一件事就是close掉所有的文件描述符;所以后续父进程fork出子进程后,子进程需要关闭对应的文件描述符。
2024-05-21 17:46:54 410 1
原创 当全连接队列满了,tcp客户端收到服务端RST信令的模拟
当tcp服务端全连接队列满了后,并且服务端也不accept取出连接,客户端再次连接时,服务端能够看到SYN_RECV状态。但是客户端看到的是ESTABLISHED状态,所以客户端自认为成功建立了连接,故其写往服务端写数据,发现数据也确实写成功了。但是后面等到服务端通过ACK+SYN告知客户端重新ACK时,发现此时客户端的业务数据已经到来了,故而认为出了问题,故重置连接。其中104代表连接被对端重置。
2024-04-16 19:33:54 349
原创 tcp的全连接队列和半连接队列满时,客户端再connect发生的情况
为何ESTABLISHED的数量是3,不是2,即刚好比全连接队列的长度大1,这里本人给出自己的看法,即在最后一个连接(即第3个)建立后,再往accept队列塞的时候,发现队列已经满了,所以就不塞了,但是连接已经建立好了。所以数目是队列的长度+1。为模拟这种情况,可以先将服务端的accept函数注释掉,这样accept queue中的连接无法被消费,从而很快就满了,而且为了快速达到效果,本人在sysctl.conf中,设置net.core.somaxconn=2,即全连接队列的长度为2.
2024-04-09 20:31:20 1130
原创 linux printf往文件里面写入内容
代码里面,先将fd=1关闭掉,然后open一个文件,出来的文件描述符fd1的值就是1,然后printf向fd为1的文件里面写入东西,执行时,最终可以看到log.txt里面的字符串。为何fsync不行,fflush可以,难道是因为printf和fflush都是stdio.h里面的吗,有大神知道原因的,请不吝赐教。此时相当于疯狂往log.txt里面写入,很快发现log.txt文件很大。最后将fsync(fd1);此种请看下,程序一直在运行,每隔1秒写入一行内容,但是可以发现log.txt中看不到任何内容。
2023-11-21 17:37:16 646 5
原创 AF_UNIX和127.0.0.1(AF_INET)回环地址写数据速度对比(二)
由于测试时发送的是1.15G大小的文件,比较快就发送结束了,而且读文件,写文件是个比较费时的操作,本人考虑到读写文件费时的影响,决定发送端自己构造字符串,接收方只统计接收到的字符个数,并不写文件。然后发送端发送100秒,对比下100秒之内,AF_UNIX和回还地址接收到的字节个数。然后利用的是发送端读取大文件,接收方接收并保存为文件的方式进行测试,结果发现,AF_UNIX并未比127.0.0.1(AF_INET)回环地址优秀,若单次发送的字节数少时,回环地址反而更快。
2023-10-09 16:13:36 706
原创 AF_UNIX和127.0.0.1(AF_INET)回环地址写数据速度对比
本人想当然认为AF_UNIX速度比127.0.0.1更快,为此鄙人进行了实验。2. 用127.0.0.1写客户端和服务端,由客户端读取文件,发送给127.0.0.1服务端,然后服务端写文件,看看用127.0.0.1传递一个文件需要多久。用AF_UNIX写客户端和服务端,由客户端读取文件,发送给AF_UNIX服务端,然后服务端写文件,看看用AF_UNIX传递一个文件需要多久。今天发现linux服务端创建socket的时候,协议族用AF_UNIX即可,AF_LOCAL和AF_UNIX的值是一样的。
2023-10-08 19:42:27 1051 6
原创 cgroup限制cpu使用率
现在想限制该cpu使用率为20%,可以通过cgroup来限制,进入/sys/fs/cgroup/cpu,通过mkdir创建cputest目录,然后进入到该目录,这里面有两个文件需要说下:cpu.cfs_period_us和cpu.cfs_quota_us,cpu.cfs_quota_us表示一个调度周期内,可以使用的cpu时间,故cpu.cfs_quota_us/cpu.cfs_period_us就是cpu使用率。,发现cgroup限制内存需要在内存涨起来之前就进行限制,cpu限制是否也有这个约束呢。
2023-09-29 20:54:31 1649
原创 coturn中turnutils_peer和turnutils_uclient使用说明
由于本人是在xxx.xxx.251.92启动的turnutils_peer,故-e后面也是这个地址。说下,turnserver.conf中,relay-ip=10.0.0.143,这个需要配置,否则loss率是100%。最后,本文的turnutils_peer和coturn服务地址在一个主机上,并且都是在公网上,若分开放,效果会更好。敲这个命令后,会向turnserver申请转发端口,如下所示,22947就是其中分配成功的一个转发端口。后面抓回路地址的包,可以看到流由coturn转发至此34800端口。
2023-05-05 18:44:21 1165 1
原创 无法解析的外部符号 __mingw_vsprintf
windows下的ffmpeg是采取mingw平台上编译,本人采用的是msys2,本人需要h264,于是先在msys2里面编译了x264静态库,注意这里是静态库,动态库经过了链接,不会出现下面的问题,然后在ffmpeg里面用下面配置命令生成Makefile。符号__mingw_vsprintf找不到,本人很好奇,在x264的代码里面搜索__mingw_vsprintf调用的地方,很明显没有直接搜找到,于是到msys2里面的stdio.h,搜寻此符号,还真找到了,如下图所示。再次编译,编译通过。
2023-04-22 23:53:06 1622
原创 vs2017编译libass静态库,并添加到ffmpeg中去,以支持ass,subtitles滤镜
vs2017编译出libass,支持ffmpeg内嵌字幕
2023-02-04 18:08:09 1216
ffmpeg_x264_dll.rar
2021-11-23
ffmpeg-snapshot.tar.bz2
2021-10-23
vs2017_build_static.rar
2021-10-23
ffmpeg_x64_dll.rar
2021-10-23
ParentChildEmbeded.rar
2021-03-07
CrashAPI.rar
2021-01-24
log4cxxTest.rar
2021-01-15
ProcessEmbedded.rar
2020-04-30
dll_killer.rar
2020-04-23
oracle 64位客户端和sdk下载
2020-02-17
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人