Проект Alsa использует MTrace с большой информацией о утечке памяти [дубликат]
Вы неправильно используете Ajax. Идея состоит в том, чтобы не возвращать что-либо, а вместо этого передавать данные на вызов, называемый функцией обратного вызова, которая обрабатывает данные.
То есть:
function handleData( responseData ) {
// Do what you want with the data
console.log(responseData);
}
$.ajax({
url: "hi.php",
...
success: function ( data, status, XHR ) {
handleData(data);
}
});
Возвращение чего-либо в обработчике ничего не сделает. Вы должны либо передавать данные, либо делать то, что хотите, непосредственно внутри функции успеха.
3 ответа
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=MEMORY-LEAK;hb=HEAD говорит:
Memory leaks - really? ----------------------Обратите внимание, что некоторые разработчики считают, что библиотека ALSA имеет некоторые утечки памяти. Конечно, это может быть правда, но перед тем, как связаться с нами, убедитесь, что эти утечки не принудительно.
Самая большая утечка в том, что глобальная конфигурация кэшируется для следующего использования. Если вы не хотите эту функцию, просто вызовите snd_config_update_free_global () после всех вызовов snd _ * _ open * (). Эта функция освободит кеш.
Самая большая утечка информации о том, что глобальная конфигурация кэшируется для следующего использования.
Если вы не хотите эту функцию, просто вызовите snd_config_update_free_global() после всех вызовов snd_*_open*().
Эта функция освободит кеш. "& lt; ---- Valgrind все еще обнаруживает утечки.
Это может быть исправлено, если вы вызываете snd_config_update_free_global() после snd_pcm_close(handle);
Возможно, это сработает ( source ):
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
@@ -2171,7 +2171,12 @@ static int snd_pcm_open_conf(snd_pcm_t **pcmp, const char *name,
if (open_func) {
err = open_func(pcmp, name, pcm_root, pcm_conf, stream, mode);
if (err >= 0) {
- (*pcmp)->open_func = open_func;
+ if ((*pcmp)->open_func) {
+ /* only init plugin (like empty, asym) */
+ snd_dlobj_cache_put(open_func);
+ } else {
+ (*pcmp)->open_func = open_func;
+ }
err = 0;
} else {
snd_dlobj_cache_put(open_func);
Я попробовал это сам, но безрезультатно. Мой основной темп нагревается до ~ 10 ° F, скорее всего, из-за аналогичной утечки памяти. Вот некоторые из того, что дал мне valgrind , даже после использования исправления выше:
==869== 16,272 bytes in 226 blocks are possibly lost in loss record 103 of 103
==869== at 0x4C28E48: calloc (vg_replace_malloc.c:566)
==869== by 0x5066E61: _snd_config_make (in /usr/lib64/libasound.so.2)
==869== by 0x5066F58: _snd_config_make_add (in /usr/lib64/libasound.so.2)
==869== by 0x50673B9: parse_value (in /usr/lib64/libasound.so.2)
==869== by 0x50675DE: parse_array_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067680: parse_array_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A8E: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A6F: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A6F: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2) Количество потерянных байтов продолжает расти вверх и вверх.