[sr-dev] [kamailio/kamailio] dlgs v5.4.* dlgs_count wrong number (#2568)

[狐狐]

### Description

Recently I upgraded kamailio to 5.4.2 using the dlgs module. No matter how many calls I make, the dlgs_count() and dlgs_tags_count() always return 1. After viewing the source code, I found the following bugs

### Troubleshooting


#### Reproduction

dlgs_init($fu,$tu,"data");
dlgs_update();
dlgs_count("any","eq","1");
and then make several calls, the dlgs_count always return 1.

#### Debugging Data


#### Log Messages
![image](https://user-images.githubusercontent.com/26111722/100606180-033c2c80-3344-11eb-9653-ebeefbeb70a7.png)
nn
![image](https://user-images.githubusercontent.com/26111722/100606206-0c2cfe00-3344-11eb-98ba-1773046ec951.png)

#### SIP Traffic


### Possible Solutions

I find the `ki_dlgs_count` functions always return  1;
![image](https://user-images.githubusercontent.com/26111722/100605735-55308280-3343-11eb-9908-aa8f55e60f63.png)
I modified the retrun value = 10086, then the `dlgs_count` always return 10086 ! !
I modified the return value = dlgs_count(msg, vfield, vop, vdata); then I found the dlgs_count always return 0; obviously there is still something wrong.
then I run the dlgs_ht_dbg() in the dlgs_count (dlgs_records.c) and get some useful dbg log as above.
as the picture shows，the slots[i].astats.c_init is always 0 or -1.  I think maybe c_init is not initialized to 1 when dlgs_init . and I add the c_init's initial logic in the dlgs_add_items()  then  everything is fine !


### Additional Information


```
Linux localhost.localdomain 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
kamailio 
version: kamailio 5.4.2 (x86_64/linux
compiled on 20:13:39 Nov  9 2020 with gcc 4.8.5
```


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2568
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20201130/5a80f7ff/attachment.htm>