Custom Query (37 matches)
Results (31 - 33 of 37)
Ticket | Owner | Reporter | Resolution | Summary |
---|---|---|---|---|
#50 | [email protected]… | fixed | fsync memory leak | |
Description |
Whenever I call aefile_fsync on a valid file descriptor, the call leaks memory (details below). ==11238== 88 bytes in 1 blocks are possibly lost in loss record 57 of 106 ==11238== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==11238== by 0x447DAF: ae_opcache_get (opcache.c:329) ==11238== by 0x447C05: aethread_hint (aethread.c:177) ==11238== by 0x444F76: ae_worker_aefile_fsync (aefile.ae:88) ==11238== by 0x445BB0: aefile_fsync (aefile.ae:84) |
|||
#54 | carns | carns | fixed | cancel-sem-forloop failure |
Description |
See resources/sem/test/cancel-sem-forloop failure. Produces a segmentation fault when cancelling aesop_sem_down() calls if the caller issues an aesop_cancel_branches() call in the same set of pbranches that have already been cancelled by a higher level caller. The workaround is to explicitly skip the aesop_cancel_branches() call if you get a CANCELLED return code from an aesop_cancel_branches() call, but it seems like you shouldn't have to do that. |
|||
#59 | dkimpe | carns | fixed | aesop backtrace function |
Description |
(copied from http://trac.mcs.anl.gov/projects/triton/ticket/174) It would be useful if the auto-generated aesop code could track its call stack so that a "backtrace" could be display on error or a crash. The standard stack trace isn't very meaningful because the aesop code will look like it has a random stack. |