Alan, Oh well when I saw this problem yesterday I thought that I'd misremembered what you said.
I was looking at this yesterday, the issue is this line in cpp/lib/framing/AMQFrame.cpp:71; // AMQP version management change - kpvdr 2006-11-16 // TODO: Make this class version-aware and link these hard-wired numbers to that version AMQBody::shared_ptr body(versionMap.createMethodBody(classId, methodId, 8, 0)); // Origianl stmt: // AMQBody::shared_ptr body(createAMQMethodBody(classId, methodId)); which explicitly creates an 8-0 type frame body. What I don't currently understand is why this is only crashing the client, not the broker as well (it's in the framing code). I assume the sequence is something like client does 0.9 open connection negotiation (which doesn't use actual protocaol frames). Broker replies with 0.9 frame and then the client dies as it makes a 8.0 frame as above. Ah I seem to have answered my own question! More general Q: Do we have a wire level protocol decoder? I.E something to plugin into tcpdump or similar? It would be quite handy to debug more complex versions of problems like this. If not I guess I'll add it to Jira. On Mon, 2007-01-08 at 21:56 -0500, Alan Conway wrote: > I *thought* the client_test was passing on the 0-9 branch this morning, > but it looks like I was halucinating and/or using the wrong working > copy. It's coring at: > > #1 0x0018a291 in > qpid::framing::AMQP_MethodVersionMap::createMethodBody ( > this=0x1c6c80, classId=10, methodId=10, major=8 '\b', minor=0 > '\0') at ./../../gen/AMQP_MethodVersionMap.cpp:150 > > Kim - it looks like some code is picking up the version from XML but > some has it hard-wired. Do you know which/how many classes still have > the hard-wired version numbers? I can fix it on the 0-9 branch, I'm > just checking if there's anything special problem that I should be aware > of. > > Cheers, > Alan. >
