Snort mailing list archives
Re: Question involving segmentation fault
From: Phil Wood <cpw () lanl gov>
Date: Fri, 8 Feb 2002 10:40:00 -0700
Folks, Here is an update on the problem I reported involving CleanExit and segmentation fault. It still could be all my problem since I use a modified libpcap. However, tcpdump does not appear to have the problem. And snort only seems to have it with a specific mix of traffic and only after I cause it to quit with a TERM siganl, or in this recent case, by causing pcap_loop to "error" by using an option I have put in libpcap to "ETIMEDOUT" once the packet time is greater that a value I supplied (in this case, midnight). By doing so I've ruled out the "signal" handling mechanisms. I checked some of the global variables in CleanExit and found that I got there and set pv.pid_filename[0] = 0; However, snort never called DropStats. So, I'm thinking somewhere in while(idx != NULL) { idx->func(sig, idx->arg); idx = idx->next; } it bombed. I'm thinking that some part of the stack is being clobbered. Here is some debug information: (gdb) where #0 0x4f452525 in ?? () #1 0x0804ed98 in InterfaceThread (arg=0x0) at snort.c:1720 #2 0x0804b284 in main (argc=19, argv=0xbffff614) at snort.c:480 #3 0x401a765f in __libc_start_main () from /lib/libc.so.6 (gdb) up #1 0x0804ed98 in InterfaceThread (arg=0x0) at snort.c:1720 1720 CleanExit(SIGQUIT); (gdb) list 1694 1689 * any interfaces, and no threads 1690 * would start on the same interface 1691 * simultaneously */ 1692 #endif 1693 1694 myint = intnum; 1695 intnum++; 1696 1697 #ifdef USE_PTHREADS 1698 pthread_mutex_unlock(&pt_lock); 1699 #endif 1700 1701 if(pv.test_mode_flag) 1702 { 1703 LogMessage("\nSnort sucessfully loaded all ... 1704 CleanExit(SIGQUIT); 1705 } 1706 1707 if(pv.daemon_flag) 1708 { 1709 LogMessage("Snort initialization completed successfully ... 1710 } 1711 1712 /* Read all packets on the device. Continue until cnt packets read */ 1713 if(pcap_loop(pds[myint], pv.pkt_cnt, (pcap_handler) ProcessPacket, NULL) < 0) 1714 { 1715 if(pv.daemon_flag) 1716 syslog(LOG_CONS | LOG_DAEMON, "pcap_loop: %s", pcap_geterr(pd)); 1717 else 1718 ErrorMessage("pcap_loop: %s", pcap_geterr(pd)); ** the following message was printed by the pcap library: pcap_loop: User specified timeout occured which is what I expect for this run of snort. 1719 **1720 CleanExit(SIGQUIT); 1721 } 1722 CleanExit(SIGQUIT); 1723 1724 return NULL; /* avoid warnings */ 1725 } 1726 1727 1728 (gdb) print pv.daemon_flag $15 = 0 <- correct not running in daemon mode (gdb) print intnum <- a static int $13 = 1 (gdb) print myint <- just an int (should == 0) $14 = 135252968 ** for what its worth, if you (gdb) x/s 135252968 0x80fcbe8: "%%EOF\r" ** which is part of strings found in the general area like so: (gdb) x/s 0x80fca00 0x80fca00: "\f ÍÖf\227°\223ØL&º\f(A\204ÐfÞ\203\b4\"!\234\027\210\206mÿ\006\020dpNî\030!\rl¾G\006\fIÝ\236³zh\030&\177÷nÐí\006\203\013Ò\220Ìm0±\021\0340A¡\021\020Á\020Àä\r¡¬9\003Á\225Ã\210\210°\230T#³a\200\203#\201\202>¦\030XgÐ\"\rqä\016a\225\002\"#\210\210\217¯\204\210\034Ãdï ¶\006&\222\aÕx\217\217ÿÿÿÿä2@àr\a&ä\017\003\207ªö@ðh\034\206\233\220<6 \206H2\016A¯\210\036\017ä2\003YÈ\026E\220,»!\220£ÓL\020d4 \2060\203á\006 1 00"... (gdb) x/s 0x80fcac8: "000 n \r0000505655 00000 n \r0000506438 00000 n \r0000506665 00000 n \r0000511633 00000 n \r0000512018 00000 n \r0000512943 00000 n \r0000513090 00000 n \rtrailer\r<<\r/Size 115\r/Info 3 0 R \r/Root 1 0 R \r/ID[<3"... (gdb) x/s 0x80fcb90: "67c1346077949b560c4094b5d5ace24><367c1346077949b560c4094b5d5ace24>]\r>>\rstartxref\r513227\r%%EOF\r" Does anyone have ideas about what to poke at? I guess I could start backing off on the preprocessors. Thanks in advance, Phil On Wed, Feb 06, 2002 at 10:07:39AM -0700, Phil Wood wrote:
Folks, I've got a re-occuring problem to do with signal handling in snort. It has happened at one time or another with ever version up to the current (1.8.4-beta1). And that is, sometimes when I send a TERM signal to the snort process, it will segmentation fault. This doesn't occur always, but usually after a realtively long run (24 hours). I restart the snort process every 24 hours by issuing the kill command. The process is encapsulated in a shell script which packages up the results, moves any core files to a unique name, and restarts the snort process. I even tried using the tcpdump signal handling stuff to see if it might be some bollixed up linux libc library problem. However, nothing I've done has made any difference. It happens on redhat? and debian potato linux systems. It could be some problem I've introduced through my own munging. But, I just thought I'd ask and see if anyone else is seeing this problem. Thanks, Phil _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
-- Phil Wood, cpw () lanl gov _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
Current thread:
- Question involving segmentation fault Phil Wood (Feb 06)
- Re: Question involving segmentation fault Phil Wood (Feb 08)
- <Possible follow-ups>
- RE: Question involving segmentation fault Chip Kelly (Feb 06)