为什么dump生成core文件大小是0

今天程序崩溃了,但是生成的core文件大小是0.

用ulimit -c 查看生成core文件的大小限制是无限unlimited.

也不是磁盘大小和写入权限的问题。

但究竟是什么问题呢?

捣了半天终于搞明白,原来是文件系统造成的。

我是在vmware的虚拟机的debian linux上运行程序,文件系统用的是从host机windows 7挂载到/mnt/hgfs的windows的NTFS文件系统。

后来我把程序转移动linux自己的文件系统,崩溃的时候就生成正常的core dump文件了。

copyright blog.ykyi.net

如何从windows远程调试linux程序。

用gdb在远程linux机器上调试程序实在太不方便了。于是想到用eclipse的GUI调试。下面介绍如何从windows远程调试linux程序。

 

 

 

 

1. 在远程linux上安装gdbserver

 

 

2. windows上安装Cygwin或者MinGW。我用Cygwin编译gdb时遇到问题,用MinGW则通过了。但我想Cygwin应该也是可以的.

 

 

3. sourceforge.net上下载expat工程。这是个分析xml文件的开源库。如果跳过这步,也可以,但是gdb不能分析gdbserver发过来的xml文件。 

 

 

4. expat文件夹, ./configure –enable-shared; make; make install

 

 

5. gdb官网下载gdb源代码,解开后运行: ./configure –with-expat –target=x86_64-linux-gnu  –host=i686-pc-mingw32   注意这里的with-expat使得gdb能用解析xml文件的功能,target使得gdb能调试的目标平台的程序,这个字符串可以从l远程inux中运行gdb时开打印出来的声明处得到。Host指定了gdb运行在什么样的平台,这个字符串可以通过运行 ./config.guess 得到。

 

 

6. 然后是make; make install 三板斧。

 

 

7. 现在试一试是否工作正常。在远程linux机器上随便创建一个程序。遵守程序员世界的传统,建个hello world,注意编译时开启 -g 选项。假设源程序是 hello.c, 可执行文件是 hello

 

 

8. 在远程linux端运行 gdbserver :8383 hello 。 8383前有个冒号,8383是端口号,随便取。

 

9. hello.c 和 hello 拷贝到windows机器。

 

 

10. 在控制台介面中,运行 x86_64-linux-gnu-gdb ./Hello。注意前面的gdb名字要相应替换成第5个步骤中编译出来的gdb文件名。

 

11. gdb的控制台交互介面中输入target remote 192.168.44.129:8383 注意把IP换成远程linux机器的IP地址。

12. 试试常用的gdb命令,continue, break, run 什么的。如果能工作就能进入下一步了。

 

13. 创建一个eclipsec/c++工程,源代码则是远程linux机器的源代码.假设工程名也是hello

13. 这一步的目的是在eclipse中创建一个Remote Application Debug configuration。选Run->Debug Configuration在左边选中c/c++ remote application,再点左上角的+号增加一个configuration。在main选项卡的c/c++ application处填windows机上可执行文件hello的路径。Projecteclipsec/c++工程名。 Connection处新建一个连接,类型选linux,其它选项填ssh。我想其它的协议应该也是可以的,但是我用了ssh。 Remote Absolute File path for c/c++ application要填在远程linux机器上启动hello的路径。是否勾上skip download to target path,表示是否在windows机器编译工程然后把编译好的文件上传到远程机器。因为我选择在远程linuxmake,所以我勾选了此项。因你的需求做调整。

 

 

14. Debugger选项卡中把GDB debugger的路填上windows上前面编译出来的gdb的路径。比如我的路径是:D:\MinGW\bin\x86_64-linux-gnu-gdb.exe

 

 

15. 现在就可以用这个Debug configuration远程调试了。

 

 

因为配置远程调试环境涉及到的配置实在太繁杂,如果写一篇考虑所有细节面面俱到的文章太困难了。这篇文章仅把骨干步骤写出,如果读者在实践中遇到各种千奇百怪的问题,需要运用你自己的判断力解决。hope this article helps.

 

copyright blog.ykyi.net

 

 

packet captured和packet received by filter到底有什么区别

我用的是linux. 结论是 packet received by filter是tcpdump从内核中拿到的且匹配命令上行指定的过滤条件的包, packet captured是经由pcap_loop, 或 pcap_dispatch 或 pcap_next,把包交给回调处理过的包的数量。这两个数字的差值是tcpdump抓到的,还来不及处理的包。

下面是讨论的一些细节:

/////////////

tcpdump的最后输出. 592个包captured,  1184个包received by filter。。这个差值是不是表示有多少包tcpdump没来得及处理.

man tcpdump上写得好复杂,received by filter的数字取决于OS… 1. 包匹配不匹配命令行上指定的filter都算,如果匹配,有没有被tcpdump读出都算..   2. 只有匹配命令行上指定的filter的包才算,有没有被tcpdump读出都算.   3. 只有匹配filter才算,只有被tcpdump读出才算.

我的理解是:如果是第3种,那captured的数字和received by filter的数字就是一样的。 第2种的差值表示tcpdump来不及处理的包数量,理想状态上差值能为0.   第1种情况,基本上总是有差值。

我猜测我用的linux上应该是第2种情况. 

wangbin579() 10:18:54 
应该是匹配的才算received by filter,但奇怪的是,为啥你的系统,captured怎么少?
wangbin579() 10:19:30 
[root@hz0-12-157 ~]# tcpdump -i any tcp and port 36524 or 3306 -w all.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
10757 packets captured
11171 packets received by filter
334 packets dropped by kernel
wangbin579() 10:20:07 
我们这边系统,基本可以认为packets received by filter=packets captured + packets dropped by kernel

siu¹ººººººº() 10:23:38 
/homemus/tmp # time time tcpdump -i tunl0:1  -w tmp
tcpdump: listening on tunl0:1, link-type RAW (Raw IP), capture size 96 bytes
19508 packets captured
39021 packets received by filter
0 packets dropped by kernel
0.01user 0.02system 0:17.04elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+506minor)pagefaults 0swaps

real    0m17.139s
user    0m0.012s
sys     0m0.028s
wangbin579() 10:26:03 
如果是差是丢包,那么通过查看抓包文件,应该能看出很多不完整的session
siu¹ººººººº() 10:28:46 
我觉得差值是来不及写入磁盘的包.
siu¹ººººººº() 10:29:04 
再研究看看了。。谢谢啦/..
wangbin579() 10:30:03 
packets captured是pcap_loop所设置的回调函数所调用的,一旦调用回调函数,就用统计
wangbin579() 10:30:37 
有可能内核态部分和用户态部分,速度上不匹配,有延迟导致的?
siu¹ººººººº() 10:32:33 
我现在理解, received by filter是pcap库从内核中拿到的又匹配命令行上filter的包的数量, packets captured是经由pcap_loop, pcap_dispatch之类通过callback交付出去的包数量. 差值就是还没来得及处理的.
wangbin579() 10:32:48 
17s,每秒也就2000多个,不算多,用户态程序应该来得及处理

wangbin579() 10:33:58 
我这边系统很破,处理速度也比这个快,也没有来不及处理
wangbin579() 10:34:45 
看看我的:
wangbin579() 10:34:47 
[root@hz0-12-157 ~]# time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap         
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
294663 packets captured
295432 packets received by filter
693 packets dropped by kernel

real    0m17.676s
user    0m0.897s
sys     0m3.502s
wangbin579() 10:35:52 
量比你大7倍多,也没有出现来不及处理啊,当然我的是物理机,3G内存,
siu¹ººººººº() 10:36:59 
 那你觉得这个差值不是来不及处理的包么?。我觉得应该还是来不及处理的。我在想,可能是写到的磁盘文件系统是NFS之类的 ….我继续排查一下。
wangbin579() 10:37:43 
有可能,我的是写入本地磁盘。
wangbin579() 10:37:58 
你这种情况,我还是第一次碰到
siu¹ººººººº() 10:39:05 
我先去运维那边了解下情况…多谢啦 
wangbin579() 10:39:18 
算涨见识了,还以为一般dropped by kernel为0就代表不丢包呢,居然还有你这种情况。
你可以看看抓包文件,session是不是很多不完整,如果不完整,你的推测是对的
siu¹ººººººº() 10:39:58 
嗯。呵呵~~ 做IT,每天都会碰到挑战宇宙规律的现象。
siu¹ººººººº() 10:40:07 

мe(~ o мe(632813052) 10:41:09 
呵呵
wangbin579() 10:41:24 
其实,网络方面的问题,最复杂了。
我现在已经陷入到网络的汪洋大海之中了,各种各样的问题都会有,而且没有尽头。
早知道如此,3年前我就不搞这一块了
siu¹ººººººº() 10:42:30 
同感。写一点点代码,都非常难以调试。各种认为理所当然的假设,通通是bug的温床

@wangbin579  麻烦你在tcpdump前加个time,。。把输出贴出来。我好像看出问题来了。

[root@hz0-12-157 ~]# time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap         
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
294663 packets captured
295432 packets received by filter
693 packets dropped by kernel

real    0m17.676s
user    0m0.897s
sys     0m3.502s
wangbin579() 10:56:03 
不是加了time了吗?
wangbin579() 10:57:15 
[root@hz0-12-157 ~]# time time tcpdump -i any tcp and port 36524 or 3306 -w 3306.pcap
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
^C202061 packets captured
202523 packets received by filter
369 packets dropped by kernel
0.66user 2.50system 0:11.99elapsed 26%CPU (0avgtext+0avgdata 24208maxresident)k
0inputs+105656outputs (0major+660minor)pagefaults 0swaps

real    0m11.999s
user    0m0.661s
sys     0m2.506s
wangbin579() 10:57:26 
加两个,结果如上
siu¹ººººººº() 10:59:29 
问题找到的。我这边运行的tcpdump,根本就没有抢到cpu时间来处理.
wangbin579() 11:00:05 

siu¹ººººººº() 11:00:06 

Real  0m3.914s

User  0m0.008s

Sys   0m0.000s

跑了4秒钟,用户空间才抢到0.008秒,内核态几乎是0 ….
siu¹ººººººº() 11:00:25 
那个差值确实是没有来得及处理的包的数量。
wangbin579() 11:00:41 
奥,那你系统这么繁忙啊

siu¹ººººººº() 11:02:22 
所以,解决了一个问题又会有新的颠覆宇宙规律的问题…系统负载很高,但cpu使用率很低。。

copyright blog.ykyi.net

 

tcpcopy在视频广告组的二次开发

1.

流量筛选中的 “只导入某频道的流量”功能已经实现了。

技术层面上,实际上是通过指定正则式的方法匹配HTTP请求中的GET方法中的URL来达到过滤的目的。

所以,也可以用ty,ad_type, pf, coverid, oadid, v,plugin等出现在GET方法中的参数编写正则式来过滤流量。

 

2.

流量筛选中的“地域纬度筛选”暂时没有实现。

因为地域纬度的信息不是以参数形式出现在GET方法的URL中,需要通过IP地址或者cookie的中QQ号信息来判断。

还没最终决定是否实现这个功能。

 

3.

tcpcopy官方版本主要的应用场景是复制实时流量。所以部署的时候至少两台机器,一台线上机,另一台测试用机。为了方便压力测试,还引入了至少三台机器的高级模式。

部署起来比较麻烦。

如果“视频CPM广告的模拟投放,以及订单效果预估“只是从磁盘中读入以往的流量,针对这种场景,可以探索tcpcopy的单机离线模式,做到方便部署和使用。

 

4. 部分同学有一个误解.

"将线上的实际访问流量,复制一份保存到本地服务器,用于后续使用"

目前,tcpcopy的官方的版本没有把流量保存下来的功能,保存流量这个目前是用tcpdump的-w选项来做的。

 

另外,技术上,tcpdump只能在IP层和TCP层指定过滤条件,不能用业务的逻辑过滤流量。第1点提到的流量筛选工作在tcpcopy读入实时流量时,或者从tcpdump存下的文件中读入流量时,在应用层指定过滤条件。

copyright blog.ykyi.net

Linux抓包技术简介

Linux抓包技术简介

Author: zausiu@gmail.com

1. 简介

大多数应用常景下,我们在IP层上用AF_INET或AF_INET6作为socket的第一个参数,SOCK_STREAM或SOCK_DGRAM作为socket的第二个参数创建最为常见的IPv4或IPv6的TCP或UDP套接字。这样的套接字满足了绝大多数网络应用常景。

 

本文简单介绍三种Linux平台下抓包,截获包的技术。它们提供一些更酷的功能。每种技术的水都很深,作者个人水平有限,按照自己的理解做一般的介绍。仅仅旨在起到科谱的作用。

 

2. RAW SOCKET

参数SOCK_RAW可以作为socket函数的第二个参数传入,这样创建的套接字称为原始套接字。设置Socket的第一个参数可以让指定原始套接字开在数据链路层上或者网络层。

 

下面的语句创建在数据链路层上的原始socket。

Socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));  

在负载不大的情况下,读这个socket可以拿到本机收到的所有数据包。写入这个socket需要程序员负责填充各种包头的数据。

 

Socket(AF_INET, SOCK_RAW, xxxxx协议号);

在IP层上创建IPv4的RAW socket,可以拿到各种经由IPv4的数据包,比如ICMP包,IGMP包等。Steven的<Unix网络编程>第三版第28.4节,第二段:“系统收到的UDP包和TCP包不会传给原始套接字”。但读tcpcopy的源代码时,确实用了原始套接字在网络层读UDP和TCP包。难道书上写的过时了。见代码,来自tcpcopy:

#if (TCPCOPY_UDP)

        fd = socket(AF_INET, SOCK_RAW, IPPROTO_UDP);

#else

        fd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);

#endif

另外,在IP层上创建的原始套接字有一个选项:IP_HDRINCL,它被开启时,则内核帮助填充IP包头。Linux默认没有开启这个选项。

 

3. NF_Queue

NF_Queue是用户空间的一个库,需要内核模块NETFILTER_NETLINK_QUEUE的支持。官方网址:http://www.netfilter.org。通过这个库可以在数据包被发往用户空间处理前截获数据包,或者在数据包被发往网卡前截获数据库。截获后,可以修改数据包的内容,并决定是否丢充这个数据库。

NF_Queue可以用来编写防火墙等安全软件。

Tcpcopy使用NF_Queue丢弃测试中的程序回复给真实客户程序的数据包,使测试中程序回复的报文不影响真实客户程序。

另一个提供类似功能的库是IP_Queue,它已经被废弃。NF_Queue可以完全取代IP_Queue。我们用的tlinux,内核中built-in了NF_Queue模块。

 

4. libpcap

大名鼎鼎的Libpcap是一个古老的可以工作在所有Unix-like平台上的抓包库,比linux年纪更大。Tcpdump的广泛使用让libpcap成为事实上的行业标准。它可以很方便的编写抓取数据链路层上的数据包,并可以设置过滤条件在内核级别只复制关心的数据包,而数据链路层上的原始套接字会尽最大努力复制所有的包,所以libpcap的工作效率高。而且,pcap使用方便。下面是一个很简单的使用pcap抓到发往80端口的tcp包并打印源IP,目的IP,和目的端口号的程序。非常短,很容易看,起到介绍libpcap的作用。

 int main(int argc, char *argv[])

 {

pcap_t *handle; // pcap用的句柄,和其它各种句柄一样。

char *dev;         // 网络接口名,如eth0, eth1, tunl0 之类

char errbuf[PCAP_ERRBUF_SIZE]; // 存描述出错原因的缓冲

struct bpf_program fp;         // pcap用来过滤数据包用

char filter_exp[] = "tcp and dst port 80"; // 过滤字符串,和tcpdump的写法一样

struct pcap_pkthdr header;      // pcap自己用的包头

const u_char *packet;         // pcap包头后的数据,即抓到的数据

 

int len_of_iphdr;         // ip头的长度

struct in_addr src_ip;    // 源IP地址

struct in_addr dst_ip;    // 目的IP

const u_char *ip_hdr_addr; // IP头的首地址

const u_char *tcp_hdr_addr;     // tcp头的首地址

struct tcphdr *tcp_hdr;         // tcp头结构体

u_short dst_port;             // 目的端口

 

// 如果命令行指定网卡名

if (argv[1])

dev = argv[1]; //就用指定的网卡

else

dev = "eth0"; //否则用eth0

 

}

        

        // 用pcap打开这个网卡

handle = pcap_open_live(dev, BUFSIZ, 0, 1000, errbuf);

if (handle == NULL) {  // 打开网卡出错

fprintf(stderr, "Couldn't open device %s: %s\n", dev, errbuf);

return(2);

}

      

        // 编译过滤文件

if (pcap_compile(handle, &fp, filter_exp, 0, net) == -1) {

fprintf(stderr, "Couldn't parse filter %s: %s\n", filter_exp, pcap_geterr(handle));

return(2);

}

        // 设置过滤条件

if (pcap_setfilter(handle, &fp) == -1) {

fprintf(stderr, "Couldn't install filter %s: %s\n", filter_exp, pcap_geterr(handle));

return(2);

}

 

        // 抓包

packet = pcap_next(handle, &header);

 

// 至此packet指向抓到的一个目标端口号是80的数据链路层的包

// 它的包结构是 14字节以太网包头 + 可变IPv4包头 + TCP包头

ip_hdr_addr = (u_char*)(packet + sizeof(struct ethernet_hdr));

src_ip.s_addr = ((struct iphdr*)ip_hdr_addr)->saddr;

dst_ip.s_addr = ((struct iphdr*)ip_hdr_addr)->daddr;

len_of_iphdr = ((struct iphdr*)ip_hdr_addr)->ihl * 4;

tcp_hdr_addr = ip_hdr_addr + len_of_iphdr;

tcp_hdr = (struct tcphdr*)tcp_hdr_addr;

dst_port = tcp_hdr->dest;

 

// 经过上面的各种指针偏移,下面打印源IP和目标IP和目标端口.

printf("src addr %s\n", inet_ntoa(src_ip));

printf("dst addr %s\n", inet_ntoa(dst_ip));

printf("dst_port %d\n", ntohs(dst_port));

 

/* And close the session */

pcap_close(handle);

 

return(0);

 }

 

5. 总结

本文只是一个非常简单的介绍。如需要进阶学习,Stevens的网络编译有更详细地关于Raw Socket的内容,研究NF_Queue技术则需要读源代码和收集散在社区各个角落的资料了,而讲libpcap有两篇很好的文章:

"Programming with Libpcap – Sniffing the network from our own application "用Libpcap编程,在我们的程序中嗅探网络。非常漂亮的pdf文档。

http://recursos.aldabaknocking.com/libpcapHakin9LuisMartinGarcia.pdf

The Sniffer’s Guide to Raw Traffic 嗅探器教程。斯坦福大学的Geek于大概2001年写的。

http://yuba.stanford.edu/~casado/pcap/section1.html

copyright blog.ykyi.net

Linux是从什么时候开始支持线程的.

几天前和同事吃饭,谈论到一个问题:linux从什么时候开始支持线程。他说linux中的线程出现的很晚,直到2.2.x才有。

我觉得不对啊,怎么会那么晚。然后它用手机搜索了一下,linux对POSIX线程库的支持确实很晚,直到2.6.x才有。

但我觉得POSIX线程库只不过是用户空间用来创建线程的接口,并不能证明那么晚linux才支持线程。

后来用PC的时候搜索了一下,在The Linux Document Project的官方网站找到了答案:

http://www.tldp.org/FAQ/Threads-FAQ/Support.html

Does Linux support threads?

Yes. As of 1.3.56, Linux has supported kernel-space multithreading. There also have been user-space thread libraries around as early as 1.0.9. There is on-going effort to refine and make the kernel more reentrant. With the introduction of 2.1.x, the memory space is being revised so that the kernel can access the user memory more quickly.

问: Linux支持线程吗?

答: 是的,自从1.3.56开始,Linux就开始支持内核空间中的多线程了。早到1.0.9,就已经有了用户空间的线程库。

/////

这里有个比较混淆的概念:内核线程, 内核态支持多线程。

内核态支持多线持指的是在内核空间支持线程的调度,创建,销毁等操作。

内核线程则是另外一个概念,它和一般task的最大区别是,描述内核线程的task_struct结构体中的内存描述符mm_struct是NULL。具体参考经典书:linux kernel development. 我另一篇贴子也有写到: http://blog.ykyi.net/2012/06/%E5%86%85%E6%A0%B8%E7%BA%BF%E7%A8%8B%E6%98%AF%E4%BB%80%E4%B9%88%E4%B8%9C%E4%B8%9C-what-is-kernel-threads/ 是从Understand the linux kernel抄下来的。