Yesterday, my copy of Deadwood 2.4.07 crashed in Windows, and I had to restart the service.
I looked at the Dr. Watson log, but the log had no useful information about why Deadwood crashed (it had an exception number of 80000007 and reported "ERROR -> ntdll!KiFastSystemCallRet: 7c91e514 c3 ret"), but appears to be something outside of Deadwood's code).
I ran some stress tests with Deadwood in Linux this morning and was unable to reproduce the crash.
I am going to close this issue as "unreproducible" unless anyone chimes in and reports Deadwood 2.4.07 crashing. It was probably caused by some bug in the Windows kernel or what not. If anyone sees this kind of crash, it would be best to include a stack trace, but I'll live if all you can give me is a Dr. Watson rerpot.
Friday, September 4, 2009
Subscribe to:
Post Comments (Atom)
3 comments:
I got a glibc exception with 2.4.07 two days ago as well, running on linux. Unfortunately I lost the original error message, no other crash since. I noticed that the memory usage is higher too and seems continuously growing, compared to 2.3.04. Probably a memory leak somewhere?
There isn't an obvious memory leak; one test I run on Deadwood before releasing an update is to make sure simple DNS queries don't report any memory leaks (nor other errors) in Valgrind.
I haven't seen it again, but what I will do is run stress test while using Valgrind with Deadwood and see if anything pops up.
OK, I just ran Valgrind with Deadwood 2.4.07 and than gave Deadwood a bunch of DNS queries. Nothing:
ERROR SUMMARY: 0 errors from 0 contexts
LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks. possibly lost: 0 bytes in 0 blocks.
So, whatever it may be, I don't see any errors nor leaks when just running a bunch of DNS queries with Deadwood. If it is something, it's an obscure corner case.
I will audit the differences between Deadwood 2.4.06 and 2.4.07 to see if anything looks bad.
Post a Comment