(gdb) where
#0  0x00000000 in ?? ()
#1  0xb684f6b4 in pn_class_incref (clazz=0xefab00, object=0xbdc130)
    at /home/qpid/git/qpid-proton/proton-c/src/object/object.c:75
#2  0xb684ff84 in pn_incref (object=0xbdc130)
    at /home/qpid/git/qpid-proton/proton-c/src/object/object.c:247
#3  0xb6866164 in pn_link_incref (object=0x12bf378)
    at /home/qpid/git/qpid-proton/proton-c/src/engine/engine.c:1020
#4  0xb684f6b4 in pn_class_incref (clazz=0xb6895410 <clazz>, object=0x12bf378)
    at /home/qpid/git/qpid-proton/proton-c/src/object/object.c:75
#5  0xb684ff84 in pn_incref (object=0x12bf378)
    at /home/qpid/git/qpid-proton/proton-c/src/object/object.c:247
#6  0xb6863ac8 in pn_link_free (link=0x12bf378)
    at /home/qpid/git/qpid-proton/proton-c/src/engine/engine.c:346
#7  0xb6862e1c in pn_connection_release (connection=0xbf9678)
    at /home/qpid/git/qpid-proton/proton-c/src/engine/engine.c:124
#8  0xb6862ecc in pn_connection_free (connection=0xbf9678)
    at /home/qpid/git/qpid-proton/proton-c/src/engine/engine.c:141

Under what circumstances could this come about? It looks as though the call to 'clazz->reify(object)' is returning 0 which would be because 'pni_head(object)->clazz' was 0.

Is there something wrong with the pn_link_t object held internally? Is there any sequence that could cause this?

void pn_connection_release(pn_connection_t *connection)
  // free those endpoints that haven't been freed by the application
  LL_REMOVE(connection, endpoint, &connection->endpoint);
  while (connection->endpoint_head) {
    pn_endpoint_t *ep = connection->endpoint_head;
    switch (ep->type) {
    case SESSION:
      // note: this will free all child links:
      pn_session_free((pn_session_t *)ep);
    case SENDER:
    case RECEIVER:
      pn_link_free((pn_link_t *)ep);

It appears the trace above went through this path. Given that the session frees associated links, how would we get here? Is the ordering which the endpoints are iterated over not always such that the parent session comes before links?

  connection->endpoint.freed = true;
  if (!connection->transport) {
    // no transport available to consume transport work items,
    // so manually clear them:

Reply via email to