[Click] thinking through the segfault in nsclick

[John McKendry]

Pursuant to my previous email about the segfault in nsclick:
 The backtrace shows these calls:
#0  0x0000000000414066 in Packet::access ()
#1  0x000000000041ca68 in Classifier::classify ()
#2  0x00007fb485ac119f in Router::initialize (this=0xdfdc00, errh=0xde1cf0)
    at ../lib/router.cc:887

 The curious thing is that the code at router.cc:887 actually
doesn't call Classifier::classify(), it says this (with surrounding context):

    _element_configure_order.assign(nelements(), 0);
    if (_element_configure_order.size()) {
	Vector<int> configure_phase(nelements(), 0);
	for (int i = 0; i < _elements.size(); i++) {
887>	    configure_phase[i] = _elements[i]->configure_phase();
	    _element_configure_order[i] = i;
	}

 I saw this earlier but didn't think about it. Now that I think about, it's
awfully strange that a call to <some-element>->configure_phase(void)
ends up at (ns-2.30/)Classifier::classify(Packet*). So I looked at the
.click file, nsclick-simple-lan.click, and sure enough, the first Click element
is a Classifier.

 So it's the namespace thing, isn't it? I need to put the Click:: namespace
stuff back so that nsclick will know the difference between a Click Classifier
and an ns Classifier, don't I?

 Dang. Back to the drawing board, as engineers used to say. I would be
interested to hear from anyone who has managed to get COPE incorporated
into a recent version of Click and nsclick.

John