summaryrefslogtreecommitdiff
path: root/qemu-options.hx
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2017-07-27 16:47:08 +0200
committerPaolo Bonzini <pbonzini@redhat.com>2017-08-01 17:27:33 +0200
commit393c13b940be8f2e5b126cd9f442c12e7ecb4cac (patch)
treeb6f47328533360c9c40e327e1fb17f53b7fc581c /qemu-options.hx
parentf5aa69bdc3418773f26747ca282c291519626ece (diff)
downloadqemu-393c13b940be8f2e5b126cd9f442c12e7ecb4cac.tar.gz
bt: stop the sdp memory allocation craziness
Clang static analyzer reports a memory leak. Actually, the allocated memory escapes here: record->attribute_list[record->attributes].pair = data; but clang is correct that the memory might leak if len is zero. We know it isn't; assert that it is the case. The craziness doesn't end there. The memory is freed by bt_l2cap_sdp_close_ch: g_free(sdp->service_list[i].attribute_list->pair); which actually should have been written like this: g_free(sdp->service_list[i].attribute_list[0].pair); The attribute_list is sorted with qsort; but indeed the first entry of attribute_list should point to "data" even after the qsort, because the first record has id SDP_ATTR_RECORD_HANDLE, whose numeric value is zero. But hang on. The qsort function is static int sdp_attributeid_compare( const struct sdp_service_attribute_s *a, const struct sdp_service_attribute_s *b) { return (int) b->attribute_id - a->attribute_id; } but no one ever writes attribute_id. So it only works if qsort is stable, and who knows what else is broken, but we can fix it by setting attribute_id in the while loop. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'qemu-options.hx')
0 files changed, 0 insertions, 0 deletions