Hi, > Earlier you said "random hangs are back". When this happens, does the whole > device become unresponsive or just dvbv5-zap? The device completely freeze, you can't even switch numlock on/off. I said "the issue is back", it is because I **thought** it was gone. To be more precise: - on raspberry zero W, the issue is gone since Mauro's patch (https://git.linuxtv.org/v4l-utils.git/commit/?id=22b06353227e04695b1b0a9622b896b948adba89) - on raspberry 2, the issue, it is still there and the patch has no effect (the issue was and is still there) > Since this issue is "back", > I wouldn't be surprised this is unrelated to the fixes in 1.12.7 and 1.16.4. The issue doesn't appear anymore on raspberry zero W since Mauro's commit. So it did improve on that platform. > It would be useful to see the output from dmesg (best thing would be after > the issue occurs). You can't, device is frozen. Logs are not flushed to disk, and journalctl -f freeze before showing anything > Also what dvb hardware are you using? I reproduced it with different two tuners: rtl2832U from RTL-SDR.COM and a TerraTec Cinergy T Stick+ You can found all the details here: https://bugs.launchpad.net/raspbian/+bug/1819650 Sam Le mar. 26 mars 2019 à 14:26, Sean Young <sean@xxxxxxxx> a écrit : > > Hi Sam, > > On Tue, Mar 26, 2019 at 08:35:44AM +0100, Samuel CHEMLA wrote: > > Hi, > > > > > > I am struggling with valgrind because it always complain with either : > > ASan runtime does not come first in initial library list; you > > should either link runtime to your application or manually preload it > > with LD_PRELOAD > > -> When I LD_PRELOAD, I'm getting a segfault, but I couldn't find > > any core dump > > > > or, if I link statically libasan with -static-libasan: > > Shadow memory range interleaves with an existing memory mapping. > > ASan cannot proceed correctly. ABORTING. > > ASan shadow was supposed to be located in the > > [0x00007fff7000-0x10007fff7fff] range. > > > > > > I retested again on my raspberry zero W, and I confirm i cannot > > reproduce the hang. > > Your fix did work on that device. > > I am testing with same OS (raspbian with latest updates, same kernel), > > same configure options, same USB dongle... :-( > > The only differences are CPU architecture (armv6 vs armv7), memory > > constraints, and I was not using the same channels.conf, I'll fix that > > today and re-check > > Earlier you said "random hangs are back". When this happens, does the whole > device become unresponsive or just dvbv5-zap? Since this issue is "back", > I wouldn't be surprised this is unrelated to the fixes in 1.12.7 and 1.16.4. > > It would be useful to see the output from dmesg (best thing would be after > the issue occurs). > > Also what dvb hardware are you using? > > Thanks, > > san > > > > > > > Sam > > > > On 25/03/2019 18:08, Mauro Carvalho Chehab wrote: > > > > Em Mon, 25 Mar 2019 17:33:30 +0100 > > Samuel CHEMLA <chemla.samuel@xxxxxxxxx> escreveu: > > > > Hi guys, > > > > I'm afraid I'm coming with sad news. > > I just tried both stable-1.12 and stable-1.16 on a raspberry pi 2, and > > random hangs are back (see https://bugs.launchpad.net/raspbian/+bug/1819650 > > ). > > I previously test both branches on a raspberry zero and issues were gone > > (same raspbian version). > > There may be more memory issues somewhere... > > > > Could you test it with valgrind? > > > > Sam > > > > Le jeu. 21 mars 2019 ŕ 20:59, Gregor Jasny <gjasny@xxxxxxxxxxxxxx> a écrit : > > > > Hello, > > > > On 21.03.19 12:30, Mauro Carvalho Chehab wrote: > > > > I went ahead and cherry-picked the relevant patches to -1.12, -1.14 and > > -1.16, and tested both dvbv5-zap and dvbv5-scan with all versions. So, > > > > we can > > > > release a new minor version for all those stable branches. > > > > After the patches, on my tests, I didn't get any memory leaks or > > double-free issues. > > > > I issues a new 1.12, 1.14, and 1.16 release. > > > > Thanks, > > Gregor > > > > > > > > Thanks, > > Mauro
