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