- 26 8月, 2019 8 次提交
-
-
由 huili 提交于
-
由 huili 提交于
-
由 huili 提交于
-
-
由 huili 提交于
-
由 Hongze Cheng 提交于
-
由 Hongze Cheng 提交于
-
由 Hongze Cheng 提交于
-
- 24 8月, 2019 14 次提交
-
-
由 Jeff Tao 提交于
fix & enhancement for udp connection handling
-
由 陶建辉(Jeff) 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 haojun Liao 提交于
标点符号错误修正
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
由 haojun Liao 提交于
fix memory leak in taos_query_a
-
由 johnnyhou327 提交于
-
由 johnnyhou327 提交于
-
- 23 8月, 2019 4 次提交
-
-
由 weixin_48148422 提交于
restful commands with length between 65380 and 65536 can trigger this issue.
-
由 黄科 提交于
-
由 slguan 提交于
-
由 slguan 提交于
-
- 22 8月, 2019 8 次提交
- 21 8月, 2019 2 次提交
- 19 8月, 2019 1 次提交
-
-
由 slguan 提交于
-
- 18 8月, 2019 1 次提交
-
-
由 weixin_48148422 提交于
1. potential data race in `taosProcessMonitorTimer`: the issue does not exist at present because there's only one scheduler thread, which means there's no cocurrent calls to this function for a same `pMonitor`. but if more scheduler threads are created later, there's a data race issue in rare case. as threads number can be easily increased by increase the value of `taosTmrThreads`, it is very unlikely that the developer could realize this function need to be revised together. that's why i say it is a 'potential' issue. this issue happens in below scenario: a. scheduler thread1: `if (pSet)` is true and new timer is installed by `taosTmrReset`; b. scheduler thread1: `if (pMonitor->pSet == NULL)` is true but `taosTmrStopA` is blocked, either by the mutex of the timer or os thread scheduler. c. timer thread: 200ms elapse, new call to `taosProcessMonitorTimer` is initialized in scheduler thread2; d. scheduler thread2: `if (pMonitor->pTimer != tmrId)` is false; e. scheduler thread1: unblocked, stops timer and frees `pMonitor`; f. scheduler thread2: unexpected behavior because `pMonitor` is not valid any more. because the result of this issue is crash or worse, i suggest to fix it though the possibility of all the conditions are met is very very low. 2. `pthread_attr_t` related issues: per manual, an initialized `pthread_attr_t` can be reused, should be destroyed, and the behavior of re-init it is undefined. this issue exist in other modules also. 3. memory leaks; 4. improve failure case handling of `taosInitUdpConnection`; 5. typo
-
- 17 8月, 2019 2 次提交
-
-
由 Hongze Cheng 提交于
-
由 slguan 提交于
[taosdemo] repeat insertation if failed, report failure when inserting 5 times
-