Multiple "Possible SleuthkitServer X crash reading..." non problematic files

[lfcnassif]

This is related to robustImageReading option. I got above error printed in console several times yesterday for 2 different processings of the same evidence, but it usually doesn't happen for this same evidence. Looking at the log, before the first error there is one "Timeout waiting SleuthkitServer X response! Restarting...". Analyzing the code and log, I found a race condition in timeout control in inter process communication.

I'll push the fix for the race condition to don't trigger the timeout wrongly, but I'm still analyzing why the error in the title happened indefinitely in a loop...

[lfcnassif]

This is important to fix since robustImageReading is enabled by default in 4.0

[lfcnassif]

@tc-wleite since you have used this option for a long time, have you observed similar errors in the console?

[wladimirleite]

When I saw your first message about this issue, I remembered seeing that error message a couple of times. But I didn't pay much attention as I was testing/working in something else and it disappeared later.
I can't remember any details, but it was definitely rare.

[lfcnassif]

Thanks. Maybe it is less rare when indexTempOnSSD = false, I'm using it to compare to other cases processed the same way, so items would be read multiple times from the external process instead of from the temp folder...

[lfcnassif]

The "Possible SleuthkitServer X crash" message loop in console can be easily reproduced just killing one of them in task manager, it used to be robust against this in the past... Yesterday I tried to refactor some good portion of this code, but it is very sensitive, leading to other kinds of concurrency issues when reading files.., I'll delay this refactoring to after 4.0 and I'll just try to fix the loop.

There is also another area for improvement I remembered: each external TSK process read many files at the same time, switching between them. But if it crashes because of some FS corruption or TSK bug reading some file, or forcibly, that affects all files being read, even those without problems. I think it is possible to resume reading other files from the point they were with some improvements, but not sure if I'll implement that for 4.0...

[lfcnassif]

This is not happening on 3.18.15, removing its tag.

[lfcnassif]

This is not working on 3.18.15, removing its tag.

sorry, not happening!

[lfcnassif]

Well, tricky, it takes some minutes to start the problematic loop after the first crash, so this happens with 3.18.15 too.

[lfcnassif]

Well, tricky, it takes some minutes to start the problematic loop after the first crash, so this happens with 3.18.15 too.

And, after the crash on 3.18.15, the external process is not restarted. Seems the bad loop begins when other external processes are restarted to clean possible resource leaks.

Anyway, 4.0.0-beta seems to be working fine now.