Sulley crash from sessions.py referencing self.fuzz_node.mutant.s_type

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Simple HTTP fuzzer against local XP target
2. procmon detects access violation on a test case
3. sessions.py references a null variable, crashes

What is the expected output? What do you see instead?
In the Sulley script output, I expect to see lines like this:

[03:23.34] xmitting: [1.2673]
[03:23.35] fuzzing 2674 of 18655
[03:23.35] xmitting: [1.2674]
[03:23.36] procmon detected access violation on test case #2674
[03:23.36] primitive lacks a name, type: string, default value: www.foo.bar
[03:23.36] [INVALID]:22732522 Unable to disassemble at 22732522 from thread
2240 caused access violation

And in this specific script, I see this exact output for faults discovered
prior to the Sulley crash.  When I get the crash, this is what I see:

[03:24.19] fuzzing 3731 of 18655
[03:24.19] xmitting: [1.3731]
[03:24.20] procmon detected access violation on test case #3731
Traceback (most recent call last):
  File "http.py", line 74, in <module>
    sess.fuzz()
  File "C:\dev\sulley\sulley\sessions.py", line 495, in fuzz
    self.poll_pedrpc(target)
  File "C:\dev\sulley\sulley\sessions.py", line 638, in poll_pedrpc
    msg += "type: %s, default value: %s" % (self.fuzz_node.mutant.s_type,
self.fuzz_node.mutant.original_value)
AttributeError: repeat instance has no attribute 's_type'

What version of the product are you using? On what operating system?
Sulley up-to-date SVN as of 1/14/2009.  This is Windows XP SP3.

Please provide any additional information below.

I'm not sure how self.fuzz_node.mutant loses s_type, but I added a little
try/except loop around it as a workaround for the time being.

Thanks,

-Josh

Original issue reported on code.google.com by jlw...@gmail.com on 14 Jan 2009 at 9:49

[GoogleCodeExporter]

This issue occurs when a crash is detected on a block repeater element.  The 
repeater 
class does not have an s_type attribute defined so when the crash tries to spew 
out 
the error message it fails.

To fix this issue I added the following line to the __init__ function of the 
repeat 
class in blocks.py

self.s_type = block_name + " repeater"

Original comment by aznoohwe...@gmail.com on 23 Apr 2010 at 1:56