On Mar 20, 2014, at 3:20 PM, Hadriel Kaplan <hadriel.kap...@oracle.com> wrote:
> What's the protocol (for lack of a better term) for how the Buildbot crash
> bugs get handled?
>
> Are there specific core developers who handle them, or is it whomever wants
> to fix it please do so?
The latter. The only difference between buildbot crash bugs and other bugs is
that robots don't generally do as good a job at figuring out where the problem
is, so rather than looking at the bug title to see which dissector is broken,
you have to look at a stack trace (which means you have to reproduce the bug -
it might be nice if, when a core is dumped in the buildbot tests, gdb could be
used to produce a stack trace and put it into the bug), so there's an extra
step involved in going after the bug.
> It's in packet-ieee80211.c, which is impressively big. (>25k lines!)
So is IEEE Std 802.11-2012. (>2k pages!) :-)
To be fair, IEEE Std 802.3-2012 is 634+780+358+732+844+400 = 3748 pages, so
it's about 1000 more pages (">2k" is 2793), but:
$ wc -l epan/dissectors/packet-eth.c epan/dissectors/packet-ieee8023.c
epan/dissectors/packet-ethertype.c
970 epan/dissectors/packet-eth.c
137 epan/dissectors/packet-ieee8023.c
410 epan/dissectors/packet-ethertype.c
1517 total
However, I think a lot of those 3748 pages describe various PHYs (more than I
think 802.11 has), and the different PHYs have *no* effect on the dissectors,
whereas the different PHYs for 802.11 add in some extra management frame crap
and the like.
But I digress. :-)
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
