TasksTasksSGSNMsgbAnnotation » History » Version 3
Anonymous, 02/19/2016 10:48 PM
| 1 | 1 | ||
|---|---|---|---|
| 2 | |||
| 3 | 3 | h2. SGSN msgb annotation to fix memory leaks and avoid double free |
|
| 4 | |||
| 5 | |||
| 6 | 1 | ||Mentor ||Holger Freyther|| |
|
| 7 | ||Skills ||C || |
||
| 8 | ||Length ||10 days || |
||
| 9 | |||
| 10 | 3 | ||
| 11 | h3. Goal |
||
| 12 | |||
| 13 | 1 | The msgb ownership in the SGSN is not well defined. This leads to memory leaks but also to double frees. One approach would be to add reference counting to the msgb object but the preferred option right now is to properly define ownership and enforce this. The work is mostly analytic work. One should start with all methods deleting the msgb (leaves/edges). Then find all possible paths that lead to these method and do it recursively. Linus Torvalds 'sparse' compiler can be patched to generate such information. The next step should be to introduce annotations that define what happens to the msgb when this message is called and then modify sparse to know this annotation and verify it among the paths. |
|
| 14 | |||
| 15 | 3 | ||
| 16 | h2. Issue |
||
| 17 | |||
| 18 | 1 | Ticket #55 is an example of this kind of problem. |
|
| 19 | |||
| 20 | |||
| 21 | 3 | h2. Approach |
|
| 22 | |||
| 23 | * Code review assisted with sparse |
||
| 24 | * Tooling support to avoid this kind of error in the future |
||
| 25 | |||
| 26 | |||
| 27 | h2. Learning experience |
||
| 28 | |||
| 29 | * Sparse and static analysis |
||
| 30 | * Refactoring of a meaningful amount of code |
