hi guenther, hi list ...
there are 2 annoying things happening with the pd package on debian:
first, this is the memory leak that kills pd after a certain time: ==3726== 2050332 (1118472 direct, 931860 indirect) bytes in 46603 blocks are def initely lost in loss record 157 of 158 ==3726== at 0x1B904F75: calloc (vg_replace_malloc.c:175) ==3726== by 0x1B99FEDA: snd_midi_event_new (in /usr/lib/libasound.so.2.0.0) ==3726== by 0x80E8BBF: sys_poll_midi (in /usr/bin/pd) ==3726==
second: starting with pd with -nomidi segfaults: [Switching to Thread 1076206016 (LWP 3770)] 0x400a62fe in snd_seq_get_client_info () from /usr/lib/libasound.so.2 (gdb) where #0 0x400a62fe in snd_seq_get_client_info () from /usr/lib/libasound.so.2 #1 0x080e886d in sys_do_open_midi ()
versions: pd: 0.38.4+amidi-1 libasound: 1.0.8-3
thanks ... tim
On Sat, 2 Apr 2005, Tim Blechmann wrote:
hi guenther, hi list ...
hi,
I took a look at the two problems, the second one is easy to fix, but I am at a loss for the first one. I am not very good at coding for ALSA, and it seems that snd_midi_event_new is unconditionally followed by a snd_midi_event_free().
Could you also supply me with the information how to reproduce this exactly ? I tried with "valgrind --tool=memcheck --leak-check=yes", (just running the pd test audio and midi patch) and the below message didn't show up.
As a last question, is someone else on the list having the same problems with the latest Debian package ? If so, as a last resort I can remove the ALSA sequencer support from the Debian package.
Greetings,
Guenter
there are 2 annoying things happening with the pd package on debian:
first, this is the memory leak that kills pd after a certain time: ==3726== 2050332 (1118472 direct, 931860 indirect) bytes in 46603 blocks are def initely lost in loss record 157 of 158 ==3726== at 0x1B904F75: calloc (vg_replace_malloc.c:175) ==3726== by 0x1B99FEDA: snd_midi_event_new (in /usr/lib/libasound.so.2.0.0) ==3726== by 0x80E8BBF: sys_poll_midi (in /usr/bin/pd) ==3726==
second: starting with pd with -nomidi segfaults: [Switching to Thread 1076206016 (LWP 3770)] 0x400a62fe in snd_seq_get_client_info () from /usr/lib/libasound.so.2 (gdb) where #0 0x400a62fe in snd_seq_get_client_info () from /usr/lib/libasound.so.2 #1 0x080e886d in sys_do_open_midi ()
versions: pd: 0.38.4+amidi-1 libasound: 1.0.8-3
thanks ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Could you also supply me with the information how to reproduce this exactly ? I tried with "valgrind --tool=memcheck --leak-check=yes", (just running the pd test audio and midi patch) and the below message didn't show up.
i was using a simple gem patch without any midi on one machine (well, on 24 identical ones) and on another machine a patch containing a netreceive and py. so basically, i wasn't using _any_ midi ... one installation was based on a knoppix hd install, the other one on ubuntu.
cheers ... tim
On Sun, 3 Apr 2005, Tim Blechmann wrote:
i was using a simple gem patch without any midi on one machine (well, on 24 identical ones) and on another machine a patch containing a netreceive and py.
Ok, I am going to try it with a simple Gem patch then. I had pd running over the night and couldn't see any problems (MEM usage stayed at 0.8 %).
so basically, i wasn't using _any_ midi ...
This doesn't matter if the memory leak occurs in the midi_poll routine. This routine is called just in case there is some MIDI coming in. Its even called with audio off.
As the poll routine allocates and deallocates memory regularily and it is called very often it is very vulnerable to memory corruption on the heap from other parts. This means if some other thread overwrites the info in the object allocated by snd_midi_event_new (zeroing out for example), then you could have a memory leak in snd_midi_event_new, although the problem was caused by memory corruption in another part of the system.
Also it is very common that memory corruption goes undetected if the system is compiled slighlty differently (just causing other bugs then).
Well, anyhow, just a guess, I will continue in my trials to reproduce.
Thanks,
Guenter
one installation was based on a knoppix hd install, the other one on ubuntu.
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list