GNU/Linux程序 | 迟思堂工作室

Linux系统无线网络抓包程序(分析手机WIFI MAC地址)

Linux系统无线网络抓包程序(分析手机WIFI MAC地址)
前面讲述了使用tcpdump和wireshark抓WIFI包,但这只是使用工具的层面,再深一层则是自己写代码实现这个功能。本文在前面文章《Linux系统有线网络抓包程序》的基础上添加实现无线网络的抓包功能。 首先要介绍ieee802.11的帧格式,只有知道帧格式才能正确解析对应字段,拿到我们感兴趣的信息。其次介绍Linux raw socket编程抓包。最后解析ieee802.11数据包,从而获取到MAC地址。实际上,从数据包中可以得到很...

Linux下coredump调试3:补录

Linux下coredump调试3:补录

本篇文章记录在coredump调试过程中记录的其它事项。
一般地,调试的方式多种多样,不可能将其一网打尽。就笔者而言,一般喜欢用print大法,分段注解法,版本回退法,等等。实在无招,则用coredump文件调试了。在笔者“众多”经验中,程序挂掉原因多种多样,像内存泄漏造成无内存可用,文件/socket打开未关闭被耗尽。所以编程的规范还是很关键的,这不单单是说编码命名风格,还有整体编程的设计和细心程度,比如指针的判断,数组范围不要越界,自己申请的内存要记得释放,等等。

Linux下coredump调试2:实例

Linux下coredump调试2:实例

前面文章只是给出简单演示,实际的程序运行中会遇到这样或那样的问题。所以,本文结合笔者实际编程经历,给出一些曾经遇到过的实际例子。
笔者遇到的大多数程序崩溃原因,基本上都是段错误:非法内存使用,越界。这就要在程序编码中注意代码的质量了。比如使用指针前必须先判断其合法性,释放指针后及时将指针置为NULL,使用数组注意不能超出其范围,等等。

Linux下coredump调试1:使用

Linux下coredump调试1:使用

李迟按:
调试是程序员的一项基本能力,经历过大大小小的实战,随着见识的增长,只要用心留意并做总结,相信调试的能力会越来越好。写程序不能没有bug,只是bug容易不容易被发现,bug的危害大不大。笔者使用coredump调试很多年了,也有部分的工作笔记,无奈事多人懒,一直没有好好总结。直到最近帮同学排查bug时,才真正下定决心写几篇文章。本文为开篇,主要描述coredump作用及配置的一些注意事项,并给出简单示例。

GCC编译警告选项的学习

GCC编译警告选项的学习

GCC有很多的编译选项,警告选项;指定头文件、库路径;优化选项。本文针整理一下GCC的警告选项,主要依据http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html文档,并加上自己的一点小小经验。

继续收集gcc一些编译警告

继续收集gcc一些编译警告

大约半年前,写了篇关于gcc编译警告的文章,因为忍受不了当时做的项目的刷屏式的编译警告。没想到,现在又要进行此事。因为当前的代码分支实在太多,而且又各自为政,没法通用——与当初重构的初衷已背离,当然,这是架构师要做的事,即使公司现在正在推行“匠心精神”,我还是没权力和能力想去推架构。所以,注定是一个修正几年前代码遗留warning的小弟。在修正过程中,真正认为到代码编写的重要性。这份庞大的代码我只贡献不到2%吧,但还是好好总结一下,以免自己日后再犯。

让Linux使用malloc申请更多的内存

让Linux使用malloc申请更多的内存

项目遇到一个问题,程序跑着跑着就会挂掉,从多方信息分析来看,发现在设备的linux系统中,一个进程申请的内存最大只能达到1GB,而设备所用的物理内存是2GB的。我们的程序有多个进程,但主进程只有一个,里面包括几十个线程,有的线程使用了如opencv的模块,占用内存有几百兆。而之前在文章提到的H.264转AVI,也必须将转码后的AVI格式内容放在内存,由于某些原因,系统中的内存使用峰值会达到1GB。但由于我正在搞其它的bug,这个实际是同事研究出来的,我也只是再次多方面地验证了一下。还是在这里记录一下吧。

遇到一个因socket未关闭引发的文件句柄用完问题

遇到一个因socket未关闭引发的文件句柄用完问题

“爱提踢斯”项目最近遇到一个问题,当FTP服务器磁盘没有空间时,设备会不断复位——这是测试人员反馈的。我们拿到log后,看到一个通信所用的文件打开失败。不断打印Too many open file,然后超时设备复位。同时我们看到数据库文件打开失败,无法写入数据。一个现象,看到好几处问题。还是从最初的表现来入手。虽然把bug指派给别人,但从时间、进度上考虑,周末还是去加班。而最后,解决了问题。根据老夫目测,是FTP的socket未关闭引起的。

libjpeg学习4:libjpeg-turbo之YUV

libjpeg学习4:libjpeg-turbo之YUV

libjpeg-turbo支持直接从JPEG解压成YUV格式,或者反之。这也是我当初想研究它的一个动力。看了头文件注释,它是支持YUV444(即宏TJSAMP_444),YUV422(即宏TJSAMP_422),YUV420(即宏TJSAMP_420),YUV400(即宏TJSAMP_440),YUV411(即宏TJSAMP_411)。可惜的是,只支持平面格式(plane),对于交织的如UYVY或特别的如NV12(即YUV420SP)或NV16(即YUV422SP),都没看到有支持。

libjpeg学习3:turbojpeg试用

libjpeg学习3:turbojpeg试用

turbojpeg针对ARM和X86对了优化,宣称其速度是libjpeg的2到4倍。下载其源码,值得称赞的地方是其例子,单元测试很到位。另外是它的注释,或者说是html说明文件,对于宏、函数都有详细的说明。本文就是参考源码的例子和html文档写的简单示例。由于只是试用,并无深入研究,只是在我的虚拟机里运行。对于性能测试,并未进行。

libjpeg学习2:内存篇

libjpeg学习2:内存篇

前面文章说到到libjpeg的使用示例,里面的例子实际上是文件的操作,即解压JPEG文件,因为libjpeg有对FILE操作的函数,所以代码直接用jpeg_stdio_src(&cinfo, fp);就行了,这个库会去读取JPEG文件。但是实际应用场合中,很多都不是文件,比如从网络传输过来的是JPEG数据,需要解压为RGB或YUV;又或者传输RGB数据要转换成JPEG。总之,是基于内存的操作的。