Date: Thu, 19 Aug 1999 22:23:32 +0200 From: "Fabian Thylmann" <fthylmann@stats.net> To: "Alfred Perlstein" <bright@wintelcom.net>, "Daniel Eischen" <eischen@vigrid.com> Cc: <alfred@FreeBSD.org>, <cvs-all@FreeBSD.org>, <cvs-committers@FreeBSD.org> Subject: Re: cvs commit: src/lib/libc_r/uthread uthread_kern.c Message-ID: <008301beea80$bd4fce30$1793e289@oph.rwthaachen.de> References: <Pine.BSF.4.05.9908191224440.6392-100000@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, ----- Original Message ----- From: Alfred Perlstein <bright@wintelcom.net> To: Daniel Eischen <eischen@vigrid.com> Cc: <alfred@FreeBSD.org>; <cvs-all@FreeBSD.org>; <cvs-committers@FreeBSD.org>; Fabian Thylmann <fthylmann@stats.net> Sent: Thursday, August 19, 1999 2:29 PM Subject: Re: cvs commit: src/lib/libc_r/uthread uthread_kern.c > Fabian: are you using anything in your code that uses time structures? > (select/sleep)? The only place I use anything that has time structures used for timing out is select() in various places. Those select()s get timestructs pasted that are definately above 0 seconds. the usec is always set to 0 (hardcoded). In one case the sec's are set to a hardcoded 5 seconds, in the other case it is set to a global variable that is set at startup of the program only one single time. I do not see how this could ever get corrupted, if this one variable would get corrupted, then so many others would most likely be also corrupted that are obvious to notice. It would cause the program to not work correctly anymore without causing any crash. Since I changed the uthread_kern checks for the over and underruns in my version of libc_r all problems went away. IF it actually was my fault and that variable got corrupted and changed into something that would cause seconds to be set below 0 then with the way I bugfixed my copy of libc_r I should get a lot of select() timeouts in my oppinion. And I would see this in my accounting part of the server right away. But to be on the save side, I'll add logging to make sure that my time vars I give to select() are never negative. If this is actually the same, sorry for this. But I guess pthreads should still not PANIC if this happends, right? select should just return with an EINVAL .. like Daniel Eischen pointed out. BTW, maybe this is informative.. maybe it helps finding the real cause for this problem: I noticed that rebooting the box removed the problem for at least a few hours, then it started again and the panic's happened very often. It did not depend on the time of day, thus number of traffic my server was handling, at least I do not beleive so. It was quite interesting that rebooting the system helped fix the problem for at least a few hours though. Just restarting the program did not seem to help. (I mean, on the panic it restarts anyway <G>) .... but I must admit, this all might just be a coincidents. Fabian Thylmann STATSnet sprl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008301beea80$bd4fce30$1793e289>