Am 01.10.2012 03:34, schrieb ArtemGr: > tnt::Worker::healthCheck calls exit and Tntnet trips on it: > > ==11555== Thread 11: > ==11555== Invalid read of size 4 > ==11555== at 0x8E17124: pthread_mutex_lock (pthread_mutex_lock.c:50) > ==11555== by 0x56E8654: cxxtools::MutexImpl::lock() (muteximpl.cpp:67) > ==11555== by 0x53DC588: tnt::HttpMessage::htdateCurrent() (mutex.h:147) > ==11555== by 0x53E664D: tnt::HttpReply::send(unsigned int, char const*, > bool) > const (httpreply.cpp:291) > ==11555== by 0x53E7631: tnt::HttpReply::sendReply(unsigned int, char > const*) > (httpreply.cpp:384) > ==11555== by 0x54085E7: tnt::Worker::dispatch(tnt::HttpRequest&, > tnt::HttpReply&) (worker.cpp:456) > ==11555== by 0x5408D6E: tnt::Worker::processRequest(tnt::HttpRequest&, > std::iostream&, unsigned int) (worker.cpp:240) > ==11555== by 0x5409886: tnt::Worker::run() (worker.cpp:139) > ==11555== by 0x5155F91: cxxtools::DetachedThread::exec() (thread.h:315) > ==11555== by 0x5705AFE: thread_entry (callable.tpp:314) > ==11555== by 0x8E14B4F: start_thread (pthread_create.c:304) > ==11555== by 0x8B5F70C: clone (clone.S:112) > ==11555== Address 0x137c3f90 is 16 bytes inside a block of size 40 free'd > ==11555== at 0x4C279DC: operator delete(void*) (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11555== by 0x8ABDDF1: __run_exit_handlers (exit.c:78) > ==11555== by 0x8ABDE44: exit (exit.c:100) > ==11555== by 0x5407587: tnt::Worker::healthCheck(long) (worker.cpp:507) > ==11555== by 0x54075FD: tnt::Worker::timer() (worker.cpp:492) > ==11555== by 0x5400F3D: tnt::Tntnet::timerTask() (tntnet.cpp:316) > ==11555== by 0x5705AFE: thread_entry (callable.tpp:314) > ==11555== by 0x8E14B4F: start_thread (pthread_create.c:304) > ==11555== by 0x8B5F70C: clone (clone.S:112) > Looks like a problem with a static class.
If healthCheck calls exit, it is really a fatal situation. A http request must not run too long. If a request runs too long, tntnet decides, that the processing hangs and tries to restart itself by exiting in the child process. The parent process detects it and rerun the child. So you should check, why the request runs too long. The other problem is, that exits starts destroying static classes like the mutex, which is used here. It looks like a request is just finished and tries to get that mutex and fails, since it is already destroyed. It looks like this is a very special situation in a fatal condition. Or can you really reproduce it? Another problem is, that healthCheck should call _exit instead of exit. exit really makes cleanup while _exit does not. It does not make any sense to cleanup when tntnet tries to exit in such a fatal situation. I will fix that. Tommi ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Tntnet-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tntnet-general
