对crashlog大小不一致的分析

在邮件的crashlog中，发现有这样一句crashlog与正常的crashlog不一致：11-30 09:50:51.819   216   216 D CRASHLOG: receive_inotify_events: Can't handle the event "20141130094844-uta_cat_csi_unsol_handler.c-1464.istp", no valid entry found, drop it...

正常的crashlog是10-18 09:23:28.900   202   202 D CRASHLOG: matt4--------receive_inotify_events: Can't handle the event "20131018092125-092102-0xdddd-200-cat_system_uta_cat_cntrl_statuscmds.c-7892.istp", no valid entry found, drop it...

这句log是距离11-30 09:50:53.829   170 13167 I MCDR_YMODEM: Stats: 34701312 bytes Written, 1414 Frames received with 0 CRC Errors and 0 Timeouts最近的crashlog，里面的这个istp文件就是被压缩的那个文件。

追溯这句打印语句在inotify_handler.c里找到了对应的函数：int receive_inotify_events(int inotify_fd)
这个函数里有这样一句log： LOGD("matt4--------%s: Can't handle the event \"%s\", no valid entry found, drop it...\n",
                    __FUNCTION__, (event->len ? event->name : "empty event"));也就是event->name就是那个istp的名字

同时找到event从哪来：  len = read(inotify_fd, orig_buffer, sizeof(orig_buffer));

 event = (struct inotify_event *)buffer;//get the name

这个inotify_fd是函数的参数，查看被调用的地方：int do_monitor()里receive_inotify_events(file_monitor_fd);

这个file_monitor_fd来自int do_monitor()里的  file_monitor_fd = init_inotify_handler();

在 init_inotify_handler()里fd = inotify_init1(IN_NONBLOCK);这里的inotify_init1(IN_NONBLOCK);都是黑体，是系统api，所以无法追溯到fd到底是来自哪个文件。