| … | |
… | |
| 3352 | =back |
3352 | =back |
| 3353 | |
3353 | |
| 3354 | If you know of other additional requirements drop me a note. |
3354 | If you know of other additional requirements drop me a note. |
| 3355 | |
3355 | |
| 3356 | |
3356 | |
|
|
3357 | =head1 VALGRIND |
|
|
3358 | |
|
|
3359 | Valgrind has a special section here because it is a popular tool that is |
|
|
3360 | highly useful, but valgrind reports are very hard to interpret. |
|
|
3361 | |
|
|
3362 | If you think you found a bug (memory leak, uninitialised data access etc.) |
|
|
3363 | in libev, then check twice: If valgrind reports something like: |
|
|
3364 | |
|
|
3365 | ==2274== definitely lost: 0 bytes in 0 blocks. |
|
|
3366 | ==2274== possibly lost: 0 bytes in 0 blocks. |
|
|
3367 | ==2274== still reachable: 256 bytes in 1 blocks. |
|
|
3368 | |
|
|
3369 | then there is no memory leak. Similarly, under some circumstances, |
|
|
3370 | valgrind might report kernel bugs as if it were a bug in libev, or it |
|
|
3371 | might be confused (it is a very good tool, but only a tool). |
|
|
3372 | |
|
|
3373 | If you are unsure about something, feel free to contact the mailing list |
|
|
3374 | with the full valgrind report and an explanation on why you think this is |
|
|
3375 | a bug in libev. However, don't be annoyed when you get a brisk "this is |
|
|
3376 | no bug" answer and take the chance of learning how to interpret valgrind |
|
|
3377 | properly. |
|
|
3378 | |
|
|
3379 | If you need, for some reason, empty reports from valgrind for your project |
|
|
3380 | I suggest using suppression lists. |
|
|
3381 | |
|
|
3382 | |
| 3357 | =head1 AUTHOR |
3383 | =head1 AUTHOR |
| 3358 | |
3384 | |
| 3359 | Marc Lehmann <libev@schmorp.de>. |
3385 | Marc Lehmann <libev@schmorp.de>. |
| 3360 | |
3386 | |
