Hi,

Digging deeper into these extra display handling functions showed that 
the format string escape it tries to accomplish was incorrect(*). With 
that fixed it ran 10000 fuzz test runs overnight, without problems.

I've other activities to attend to, but I hope to get back finishing up 
after the weekend.

Thanx,
Jaap

(*) format string escape was done by means of inserting a slash in front 
of a percent. That lead to a test case with "s/%nguage" format string. 
That "%n" causes trouble. Changing the escape character to "%" solved this.

Jaap Keuter wrote:
> Hi,
> 
> Yeah, that was my first idea as well. Finding the object that gets 
> altered isn't so easy though.
> Looking back at the code there are just your basic proto_tree_add_* 
> calls, but there are two extra display handling functions which look 
> oke, but may be the cause after all....
> 
> Thanx,
> Jaap
> 
> Luis EG Ontanon wrote:
>> Might be a buffer overflow overwriting it.
>>
>> - break after protocol registration.
>> - find the object that gets altered,
>> - set a watchpoint on that memory location
>> - continue until the watchpoint tells you who and where it gets overwritten.
>>
>> Luis
>>
>> On 8/15/07, Jaap Keuter <[EMAIL PROTECTED]> wrote:
>>> Hi list,
>>>
>>> I've picked up the unistim dissector a while ago and try getting it into
>>> shape for checkin. Thing is that I'm currently running fuzztests which
>>> for the most run fine, but now I've isolated a packet that causes a
>>> segmentation fault. The problem is that I'm stuck looking for the cause.
>>>

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to