Ok, i'll await Luca's fix. -- Robbert
-----Oorspronkelijk bericht----- Van: Burton M. Strauss III [mailto:[EMAIL PROTECTED] Verzonden: donderdag 10 juli 2003 13:57 Aan: [EMAIL PROTECTED] CC: Luca Deri Onderwerp: RE: [Ntop-dev] Bug (+fix?) segfault in scanTimedOutTCPSessions Actually, I've got a patch which tests the variable and returns if it's null. Both should work. + if (myGlobals.device[actualDeviceId].tcpSession == NULL) { + traceEvent(CONST_TRACE_WARNING, "session purge of NULL myGlobals.device[].tcpSession"); + return; + } + Both versions would seem to work, but since Luca was the last one messing around in there, I'm hoping he'll fix it 'right'... -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kouprie, Robbert Sent: Thursday, July 10, 2003 5:15 AM To: '[EMAIL PROTECTED]' Subject: [Ntop-dev] Bug (+fix?) segfault in scanTimedOutTCPSessions Hi, Now everything compiles / builds (Thanks to Burton), and the sudden crashes still lasted, I started digging in the code. I'm running ntop 2.2 from today's CVS. System is Dual P3-1 GHz, Linux 2.4, glibc 2.3. First segfault I encountered was in scanTimedOutTCPSessions (mind actual line number is 453, but I added some debugging print calls). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 2280)] 0x400916c5 in scanTimedoutTCPSessions (actualDeviceId=1) at sessions.c:459 459 prevSession = theSession = myGlobals.device[actualDeviceId].tcpSession[idx]; (gdb) bt #0 0x400916c5 in scanTimedoutTCPSessions (actualDeviceId=1) at sessions.c:459 #1 0x400809f6 in purgeIdleHosts (actDevice=1) at hash.c:591 #2 0x40087509 in scanIdleLoop (notUsed=0x0) at ntop.c:642 #3 0x40280d53 in pthread_start_thread () from /lib/libpthread.so.0 And in the logs: Jul 10 13:55:33 xf ntop[2280]: [MSGID00441-sessions] DEBUG: Called scanTimedoutTCPSessions (device=1, sessions=0) Jul 10 13:55:33 xf ntop[2280]: [MSGID00451-sessions] DEBUG: scanTimedoutTCPSessions: _idx=0, idx=0 (Last print statement I added myself). Now, it seems there are 0 sessions, but we are still accessing device[actualDeviceId].tcpSession[idx] with an index of 0. This is the point it segfaults. Shouldn't we bail out if 0 sessions? Like below patch does? Regards, -- Robbert --- sessions.c.orig 2003-07-10 14:10:31.000000000 +0200 +++ sessions.c 2003-07-10 14:13:33.000000000 +0200 @@ -442,6 +442,9 @@ actualDeviceId, myGlobals.device[actualDeviceId].numTcpSessions); #endif + // If zero sessions, return. + if(!myGlobals.device[actualDeviceId].numTcpSessions) return; + for(_idx=0; _idx<MAX_TOT_NUM_SESSIONS; _idx++) { IPSession *nextSession, *prevSession, *theSession; _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
