[llvm-bugs] [Bug 34322] New: False positive [Use-after-free]: a different part of the struct is freed than what is subsequently used
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Aug 25 03:22:58 PDT 2017
https://bugs.llvm.org/show_bug.cgi?id=34322
Bug ID: 34322
Summary: False positive [Use-after-free]: a different part of
the struct is freed than what is subsequently used
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: kremenek at apple.com
Reporter: jdanek at redhat.com
CC: llvm-bugs at lists.llvm.org
Created attachment 19041
--> https://bugs.llvm.org/attachment.cgi?id=19041&action=edit
report html
The report in question. One can clearly see that q->name is freed, but then
only q->messages.len is accessed.
I haven't tried creating self-contained reproducer for this. I will do that if
I am asked.
Version: clang version 6.0.0-svn309375-1~exp1 (trunk); from the debian snapshot
packages, on Debian Stretch.
165 void queues_destroy(queues_t *qs) {
166 for (queue_t *q = qs->queues; q; q = q->next) {
1 Loop condition is true. Entering loop body →
167 queue_destroy(q);
2 ← Calling 'queue_destroy' →
168 free(q);
169 }
170 pthread_mutex_destroy(&qs->lock);
171 }
80 static void queue_destroy(queue_t *q) {
81 pthread_mutex_destroy(&q->lock);
82 free(q->name);
3 ← Memory is released →
83 for (size_t i = 0; i < q->messages.len; ++i)
4 ← Use of memory after it is freed
84 free(q->messages.data[i].start);
85 VEC_FINAL(q->messages);
86 for (size_t i = 0; i < q->waiting.len; ++i)
87 pn_decref(q->waiting.data[i]);
88 VEC_FINAL(q->waiting);
89 }
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170825/8185ea6b/attachment.html>
More information about the llvm-bugs
mailing list