View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006645 | GNUnet | util library | public | 2020-11-10 19:55 | 2020-11-11 13:54 |
| Reporter | md | Assigned To | schanzen | ||
| Priority | low | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Platform | GNU/Linux | OS | Guix System | OS Version | v??? |
| Product Version | Git master | ||||
| Summary | 0006645: Trivial memory leak (and unused code) in GNUNET_CONTAINER_meta_data_serialize | ||||
| Description | The function GNUNET_CONTAINER_meta_data_serialize sometimes allocates vmd = (struct GNUNET_CONTAINER_MetaData *) md, but the result is never used or freed. On a related note, vmd->sbuf is allocated but never freed. I believe vmd shouldn't be allocated at all, and all references to vmd should be replaced by md, but I don't know the caching logic well enough to tell for sure. Discovered on gnunet-0.13.1, also present on git master. Relevant source code src/util/container_meta_data.c at line 893: if ((NULL == md->sbuf) && (0 == i)) { /* fill 'sbuf'; this "modifies" md, but since this is only * an internal cache we will cast away the 'const' instead * of making the API look strange. */ vmd = (struct GNUNET_CONTAINER_MetaData *) md; hdr = GNUNET_malloc (left + sizeof(struct MetaDataHeader)); hdr->size = htonl (left); hdr->entries = htonl (md->item_count); if (GNUNET_YES == comp) { GNUNET_assert (clen < left); hdr->version = htonl (2 | HEADER_COMPRESSED); GNUNET_memcpy (&hdr[1], cdata, clen); vmd->sbuf_size = clen + sizeof(struct MetaDataHeader); } else { hdr->version = htonl (2); GNUNET_memcpy (&hdr[1], &ent[0], left); vmd->sbuf_size = left + sizeof(struct MetaDataHeader); } vmd->sbuf = (char *) hdr; } | ||||
| Tags | low hanging fruit | ||||
|
|
vmd is never allocated. It is simply assigned. As per the comment, the reason behind this is to remove the "const" from the MetaData object "md" in order to "modify" the "sbuf" member if NULL. I do not think this is a memory leak. |
|
|
You're right, I didn't read that line properly ... The issue can be closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-11-10 19:55 | md | New Issue | |
| 2020-11-10 19:55 | md | Tag Attached: low hanging fruit | |
| 2020-11-11 10:46 | schanzen | Note Added: 0017118 | |
| 2020-11-11 11:19 | md | Note Added: 0017121 | |
| 2020-11-11 13:54 | schanzen | Assigned To | => schanzen |
| 2020-11-11 13:54 | schanzen | Status | new => closed |
| 2020-11-11 13:54 | schanzen | Resolution | open => no change required |
