On Mar 20, 2014, at 3:20 PM, Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx> 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. :-)
