With all the updates of recent times I wanted to try to use Valgrind. I got a crash with core dumps. I enclose it all in case it might be useful. Probably the crash is my fault that I tried to do several things at once. https://www.dropbox.com/s/rj0b0mhuyvg1kjl/val.log?dl=0 https://www.dropbox.com/s/25ncvd1mfwnrfgb/cinelerra_29181.dmp?dl=0
Thanks we will download it and look at it and let you know. On Thu, Dec 13, 2018 at 10:36 AM Andrea paz <[email protected]> wrote:
With all the updates of recent times I wanted to try to use Valgrind. I got a crash with core dumps. I enclose it all in case it might be useful. Probably the crash is my fault that I tried to do several things at once.
https://www.dropbox.com/s/rj0b0mhuyvg1kjl/val.log?dl=0 https://www.dropbox.com/s/25ncvd1mfwnrfgb/cinelerra_29181.dmp?dl=0 -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Andrea:
I got a crash with core dumps. I enclose it all in case it might be useful. Probably the crash is my fault that I tried to do several things at once.
Did you possibly unplug a sound device? GG has never seen anything like this before and wonders if there is something wrong with your sound device. Error is "Invalid read of size 1" in audioalso.C, line 423. Also, you might consider turning off LV2 and Ladspa paths before running valgrind just to speed things along as it slows things down. Also, starting at line 2852 there are several LSP LV2 plugin errors. Could you run without Valgrind to determine and look at the console output to see which ones look like they have errors so we can blacklist them? Thanks, Phyllis
Don't mind the audio errors in my sisytem. Some time ago I wanted to try Jack and since then the playback with CinnGG works only with Jack active (or without Jack setting Sink #0). But it's not Cin's problem, it's mine. Now with the latest version I have compiled from root in /tmp and run Valgrind to get the core dump. I noticed these behaviors (no valgrind): 1- Set Playback audio to "default": No audio, no crash. 2- Set Playback to default with Jack: No audio, no crash. 3- Set Playback to Sink #0: crash (with or without Jack). [cinelerra_19968.dmp] I then compiled normally in /home/user... It no longer behaves like the last installations, because now the audio works by default and does not work with Sink #0. I don't know if the two installations influence each other (the one in /tmp and the one in /home/....). I think so because after starting the "normal" one now the audio works also in /tmp 1-2- Yes audio, no crash. But I repeat: do not waste time with errors that do not concern CinGG. https://www.dropbox.com/s/s9pzohcv2qfekg9/cinelerra_19968.dmp?dl=0 https://www.dropbox.com/s/qwz9uy4wk0p5qrm/tmp-boot-log.txt?dl=0
Also, you might consider turning off LV2 and Ladspa paths before running valgrind just to speed things along as it slows things down.
Ahem, sorry for the incompetence but how do you avoid booting ladspa and lv2 plugins? I once tried to compile Cin forcing -without-ladspa, but they were compiled the same.
Andrea,
Ahem, sorry for the incompetence but how do you avoid booting ladspa and lv2 plugins?
Actually it is my incompetence -- you can not avoid ladspa but you can avoid lv2. In Settings -> Preferences, Interface tab, there is a field Default LV2 plugins path. Record what it is currently set to and then change to: $CIN_DAT/lv2 it automatically re-initializes. When done put back the original.
Andrea, GG analyzed the val.log you created ( https://www.dropbox.com/s/rj0b0mhuyvg1kjl/val.log?dl=0) Indeed it looks good. He did check in 1 change where some memory was leaking so the line from the log that reads: "611,536 (296 direct, 611,240 indirect) bytes in 1 blocks are definitely lost" should be gone the next time you run valgrind. If you get the chance to run again, this time could you do a little "grouping" so this new code is checked to make sure it is not leaking memory? Thanks, I do not know how you have the patience to run Valgrind as I do not! GG/Phyllis
I made the new Valgrind. I tried Grouping and Drag and then I created a proxy. But it took 3 to 16 hours and that's what I kill CinGG. I don't know if this compromises anything. https://www.dropbox.com/s/rj0b0mhuyvg1kjl/val.log?dl=0
Andrea, it is still useful, but always better without the kill. GG already looked at it and finding no new problems. That is good. gg/phyllis On Thu, Dec 20, 2018 at 12:36 PM Andrea paz <[email protected]> wrote:
I made the new Valgrind. I tried Grouping and Drag and then I created a proxy. But it took 3 to 16 hours and that's what I kill CinGG. I don't know if this compromises anything. https://www.dropbox.com/s/rj0b0mhuyvg1kjl/val.log?dl=0 -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
New valgrind without kill :-) Curiosity: when I compile CinGG, before delete .bcast5 and after I compile CinGG. In Root (for valgrind test), I have .bcast5 is in /root/: Can I delete this .bcast5? How do I it? https://www.dropbox.com/s/rj0b0mhuyvg1kjl/val.log?dl=0
I have .bcast5 is in
/root/: Can I delete this .bcast5? How do I it?
To delete the root .bcast5 directory and its contents (assuming it is the same in Arch which it should be). You always have to be *extremely cautious* when doing this. The "-ri" is recursive and it prompts you for each file to reply with "y" or "n". If you do minimum cinelerra work while logged in as root, there should not be that many files. If you are absolutely sure you will never make a mistake (and who is?) you can use "-rf" instead which forces the delete without prompting. cd /root rm -ri .bcast5
participants (2)
-
Andrea paz -
Phyllis Smith