Closed edevil closed 9 years ago
I believe this is expected. The way things work right now is the test cases aren't generated dynamically IIRC, so it loads all the potential test-cases in memory.
It's very silly, and going to be fixed in Sulley 2.
Btw, this is not Sulley's fault I think, but it is related. After running the fuzzer for a few days it crashed:
Traceback (most recent call last):
File "fu.py", line 59, in <module>
sess.fuzz()
File "/Users/andre/work/vc/sulley/sulley/sessions.py", line 539, in fuzz
self.export_file()
File "/Users/andre/work/vc/sulley/sulley/sessions.py", line 356, in export_file
fh.write(zlib.compress(cPickle.dumps(data, protocol=2)))
OverflowError: size does not fit in an int
(discosite)[andre@anarres ~/work/vc/sulley]$ python fu.py
[2014-11-17 10:18:39,769] [INFO] -> current fuzz path: -> HTTP VERBS
[2014-11-17 10:18:39,770] [INFO] -> fuzzed 0 of 271214 total cases
It looks like it's zlib's fault but still, something to watch out for. The log file was not written as well.
Eesh, yeah that's a nasty bug in 32 bit zlib.
Apparently these guys ran into it too: https://github.com/joblib/joblib/issues/122
2GB is not a great maximum size to be able to compress. It's probably worth getting off zlib for the next release then. I'll cut another issue for that.
Thanks for the info! Am I cool to close this out, or do you have any other questions?
No, I'm good. :)
I'm running a simple fuzzing script (fu.py):
This has been running for a few hours and the process is currently using 1.8GB of RAM(!).
Is this expected? Am I doing something wrong?