View Issue Details

IDProjectCategoryView StatusLast Update
0003294GNUnetconversation servicepublic2014-04-08 14:42
Reporteryids Assigned ToSree Harsha Totakura Due Date
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionwon't fix 
OSDebianOS Version7 
Product Version0.10.0 
Target Version0.10.1Fixed in Version0.10.1 
Summary0003294: list of calls keeps incrementing, even when there are not more than one incoming calls
Descriptionwhen you accept an incomming call, then reject it and receive another one, the call list seems to be incremented. Since there is only one incoming call, I guess the number of the call should be 0
Steps To Reproduceanswer an incoming call, cancel it, answer another one.
Additional Informationyids@ingorgare:~/src/gnunet$ gnunet-conversation -e ingorgare
Phone active on line 0. Type `/help' for a list of available commands
Incoming call from `pinky.gnu'. Please /accept #0 or /cancel 0 the call.
/accept
/status
You are having a conversation with `pinky.gnu'.
/cancel
/status
We are listening for incoming calls for ego `ingorgare' on line 0.
Incoming call from `pinky.gnu'. Please /accept #1 or /cancel 1 the call.
/accept 1
/status
You are having a conversation with `pinky.gnu'.
/cancel
/status
We are listening for incoming calls for ego `ingorgare' on line 0.

hark@pinky:~/src/crypto/gnunet$ gnunet-conversation -e phone-ego
Phone active on line 0. Type `/help' for a list of available commands
/call call.ingorgare.gnu
Resolved address of `call.ingorgare.gnu'. Now ringing other party.
^Chark@pinky:~/src/crypto/gnunet$ gnunet-conversation -e phone-ego
Phone active on line 0. Type `/help' for a list of available commands
/call call.ingorgare.gnu
Resolved address of `call.ingorgare.gnu'. Now ringing other party.
Connection established to `call.ingorgare.gnu'
Call terminated
/call call.ingorgare.gnu
Resolved address of `call.ingorgare.gnu'. Now ringing other party.
Connection established to `call.ingorgare.gnu'
/status
We are listening for incoming calls for ego `phone-ego' on line 0.
You are having a conversation with `call.ingorgare.gnu'.
TagsNo tags attached.
Attached Files
fix-call-numbers.patch (1,019 bytes)   
Index: gnunet-conversation.c
===================================================================
--- gnunet-conversation.c	(revision 32114)
+++ gnunet-conversation.c	(working copy)
@@ -288,6 +288,8 @@
     GNUNET_CONTAINER_DLL_remove (cl_head,
                                  cl_tail,
                                  cl);
+    GNUNET_assert (caller_num_gen > 0);
+    caller_num_gen--;
     GNUNET_free (cl->caller_id);
     if (cl == cl_active)
     {
@@ -917,11 +919,17 @@
                                  cl);
     GNUNET_free (cl->caller_id);
     GNUNET_free (cl);
+    GNUNET_assert (caller_num_gen > 0);
+    caller_num_gen--;
     break;
   case PS_ACCEPTED:
     /* expected state, do rejection logic */
     GNUNET_assert (NULL != cl_active);
     GNUNET_CONVERSATION_caller_hang_up (cl_active->caller);
+    GNUNET_free (cl_active->caller_id);
+    GNUNET_free (cl_active);
+    GNUNET_assert (caller_num_gen > 0);
+    caller_num_gen--;
     cl_active = NULL;
     phone_state = PS_LISTEN;
     break;
fix-call-numbers.patch (1,019 bytes)   

Activities

Sree Harsha Totakura

2014-01-30 18:39

updater   ~0008045

Does the uploaded patch (https://gnunet.org/bugs/file_download.php?file_id=633&type=bug) address the issue.

If possible, can you please also check with Valgrind of any memory corruption errors (double free, etc)?

Sree Harsha Totakura

2014-01-31 09:35

updater   ~0008048

Fixed in SVN #32132.

Christian Grothoff

2014-01-31 11:15

manager   ~0008049

Actually, that patch seems wrong. 'caller_num_gen' was supposed to be monotonically increasing so that each call gets a unique number. Otherwise, the user might accidentally do something like "/hangup #3" and close a different call, as #3 is hung up by the other side "during enter" and a new call could come in and be assigned #3 again --- all while the user presses "enter". So yes, the point was that the caller IDs would grow "forever", as they represent unique calls (within one application session).

Sree Harsha Totakura

2014-01-31 11:58

updater   ~0008050

True; didn't think about it. Reverted in #32133.

Issue History

Date ModifiedUsernameFieldChange
2014-01-30 17:07yidsNew Issue
2014-01-30 18:37Sree Harsha TotakuraAssigned To => Sree Harsha Totakura
2014-01-30 18:37Sree Harsha TotakuraStatusnew => assigned
2014-01-30 18:38Sree Harsha TotakuraFile Added: fix-call-numbers.patch
2014-01-30 18:39Sree Harsha TotakuraNote Added: 0008045
2014-01-30 18:39Sree Harsha TotakuraStatusassigned => feedback
2014-01-31 09:30Sree Harsha TotakuraStatusfeedback => assigned
2014-01-31 09:31Sree Harsha TotakuraFile Deleted: fix-call-numbers.patch
2014-01-31 09:31Sree Harsha TotakuraFile Added: fix-call-numbers.patch
2014-01-31 09:34Sree Harsha TotakuraProduct Version => 0.10.0
2014-01-31 09:34Sree Harsha TotakuraFixed in Version => 0.10.1
2014-01-31 09:34Sree Harsha TotakuraTarget Version => 0.10.1
2014-01-31 09:35Sree Harsha TotakuraNote Added: 0008048
2014-01-31 09:35Sree Harsha TotakuraStatusassigned => resolved
2014-01-31 09:35Sree Harsha TotakuraResolutionopen => fixed
2014-01-31 11:15Christian GrothoffNote Added: 0008049
2014-01-31 11:15Christian GrothoffStatusresolved => assigned
2014-01-31 11:58Sree Harsha TotakuraNote Added: 0008050
2014-01-31 11:58Sree Harsha TotakuraStatusassigned => resolved
2014-01-31 11:58Sree Harsha TotakuraResolutionfixed => won't fix
2014-04-08 14:42Christian GrothoffStatusresolved => closed