![[RTEMS Logo]](/images/logo.png){kind=logo}
Opened on 04/20/15 at 15:55:08
Closed on 10/01/20 at 23:05:45
#2331 closed defect (fixed)
c/src/lib/libbsp/sparc/shared/1553/gr1553b.c: 2 * memory leak ?
| Reported by: | David Binderman | Owned by: | Daniel Hellstrom |
|---|---|---|---|
| Priority: | normal | Milestone: | 4.11.4 |
| Component: | arch/sparc | Version: | 4.11 |
| Severity: | normal | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
1.
[rtems/c/src/lib/libbsp/sparc/shared/1553/gr1553b.c:231]: (error) Memory leak: priv
if ( ambadev == NULL ) {
return DRVMGR_FAIL;
}
2.
[rtems/c/src/lib/libbsp/sparc/shared/1553/gr1553b.c:260]: (error) Memory leak: priv
return DRVMGR_OK;
}
Change History (12)
comment:1 Changed on 04/20/15 at 16:04:11 by Gedare Bloom
| Owner: | set to Daniel Hellstrom |
|---|---|
| Status: | new → assigned |
comment:2 Changed on 04/20/15 at 16:04:57 by Joel Sherrill
comment:3 Changed on 04/28/15 at 08:18:09 by Daniel Hellstrom
case 1 is a memory leak. It should be safe for the driver to assume that dev->businfo always is initialized, setting it to NULL makes no sense when a device have been created. Rather it should check if the APB registers are present.
case 2. is ok as Joel points out.
The driver does not implement the drvmgr device remove() function, so the memory is never freed.
I will suggest a pacth.
comment:4 Changed on 01/26/17 at 07:16:00 by Sebastian Huber
| Milestone: | 4.11.1 → 4.11.2 |
|---|
comment:5 Changed on 03/23/17 at 01:03:28 by Chris Johns
| Milestone: | 4.11.2 → 4.11.3 |
|---|
The 4.11.2 milestone is closing.
comment:6 Changed on 03/23/17 at 01:05:42 by Chris Johns
| Version: | 4.10 → 4.11 |
|---|
Move to the 4.11 branch.
comment:7 Changed on 08/30/17 at 10:44:27 by Daniel Hellstrom
Fixed in master by 360fb2fe75c88a5cc6ebff08f37fe60936352f62.
comment:8 Changed on 02/05/18 at 05:54:09 by Chris Johns
Should this change also be fixed on the 4.11 branch?
comment:9 Changed on 02/07/18 at 22:01:28 by Chris Johns
| Component: | unspecified → arch/sparc |
|---|
comment:10 Changed on 02/11/18 at 23:40:41 by Chris Johns
| Milestone: | 4.11.3 → 4.11.4 |
|---|
Move to the next milestone and Daniel will resolved them for the next release.
comment:11 Changed on 10/01/20 at 01:30:57 by Chris Johns
Can the fix in master be applied to the 4.11 branch?
comment:12 Changed on 10/01/20 at 23:05:45 by Daniel Hellstrom <daniel@…>
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
In [changeset:"a100457c7d59fa2111429efc6b7b1b70f9f6984f/rtems" a100457/rtems]:
I believe case 1 is a leak on the error case.
Case 2 looks OK. The two malloc'ed chunks of memory have been placed on a list for future use.
Are two free's called on the close path?