I've checked in a change which fixes the infinite-loop problem
of the DNS dissector, at least for the random packets I generated.
It seems to work, but one time when I was using it to read that
10-packet file I sent out earlier, it segfaulted. A quick jump into
gdb showed a long stack of gtk function calls. This segfault occured
when I was highlighting and opening and closing subtrees in these
bad DNS packets.
I unfortunately re-compiled ethereal, so I can no longer get
good symbol information from that core file using gdb, and so far I
am unable to reproduce the problem.
It's important that we get the bugs dealing with bad packets out of ethereal.
I really recommend trying 'randpkt', it's very good at producing bad
packets. It's very easy to add new protocols to randpkt. At first
glance it seems that I put protocols in randpkt in a really stupid
fashion... they're just pre-recorded packet headers in guint8 arrays.
I could have done something more intelligent like be able to chain
protocols on the command-line (randpkt -p eth+llc+ip+udp+dns).
But this straight-forward method makes it easy to add new protocols quickly.
Also, here's a hint. I was able to do some debugging on ethereal
even during this infinite loop when GTK+ had control of my keyboard,
as Guy mentioned. I ran gdb and ethereal from my console (on my Linux machine),
so that the keyboard control was from the Linux virtual console, not
X11. But my DISPLAY was set to localhost:0. I would switch back and
forth between my virtual console and my X11 session.
So even when GTK+ locked up X11 keyboard input, I could still
(luckily) use Ctrl-Alt-F1 to go back to my Linux console and
interact with gdb. From that I was able to tell that the loop was
happening in dissect_query_records, and then again in
dissect_answer_records.
--gilbert
