<div dir="ltr"><div class="gmail_default" style="font-size:small">Andrew,</div><div class="gmail_default" style="font-size:small">Today's GIT checkin fixes this. The problem appears to only occur on a 32-bit system running out of memory. Because 64 bit systems handle it better. The fix limits the cache demand. Plus there is now a check so that if out of memory, instead of SEGV, it will EXIT.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 14, 2020 at 12:49 AM Andrew Randrianasulu via Cin <<a href="mailto:cin@lists.cinelerra-gg.org">cin@lists.cinelerra-gg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">В сообщении от Monday 14 September 2020 07:52:07 Georgy Salnikov написал(а):<br>
> On Mon, 14 Sep 2020, Andrew Randrianasulu via Cin wrote:<br>
> <br>
> > Aw, no, sorry this time it crashed again (maybe having Seamonkey in<br>
> > background makes this issue more visible)<br>
> <br>
> There may be two additional methods of hunting such sporadic<br>
> bugs/weaknesses. Where some rare bugs might become exposed.<br>
> <br>
> 1) Try to run program on a very poor computer (a single core, few memory,<br>
> economy graphic board, or may be even 32 bit platform).<br>
<br>
I think I can do this!<br>
<br>
I tried this file (720x400 , 25 fps, h264)<br>
<br>
<a href="https://cloud.mail.ru/public/4TUh/4SXe5ec1a" rel="noreferrer" target="_blank">https://cloud.mail.ru/public/4TUh/4SXe5ec1a</a><br>
<br>
LANG=ru_RU.utf8 DRI_PRIME=1 taskset -c 0 cin<br>
<br>
taskset set cin to use only 1st CPU core.<br>
<br>
DRI_PRIME=1 set cin to use my second (faster) GPU<br>
<br>
<br>
cpufreq-info<br>
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009<br>
Report errors and bugs to <a href="mailto:cpufreq@vger.kernel.org" target="_blank">cpufreq@vger.kernel.org</a>, please.<br>
analyzing CPU 0:<br>
driver: acpi-cpufreq<br>
CPUs which run at the same hardware frequency: 0<br>
CPUs which need to have their frequency coordinated by software: 0<br>
maximum transition latency: 4.0 us.<br>
hardware limits: 1.40 GHz - 3.80 GHz<br>
available frequency steps: 3.80 GHz, 3.40 GHz, 2.60 GHz, 1.80 GHz, 1.40 GHz<br>
available cpufreq governors: ondemand, userspace<br>
current policy: frequency should be within 1.40 GHz and 3.80 GHz.<br>
The governor "userspace" may decide which speed to use<br>
within this range.<br>
current CPU frequency is 1.40 GHz (asserted by call to hardware).<br>
cpufreq stats: 3.80 GHz:15,48%, 3.40 GHz:5,42%, 2.60 GHz:6,62%, 1.80 GHz:20,96%, 1.40 GHz:51,52% (458934)<br>
<br>
so, I set cpu frequency to lowest possible value.<br>
<br>
Next I splice video in two, add 1v/2a tracks to proj, move second half under first, set play<br>
from very beginning, add faders to both video tracks ...play/fast play back/forward, mouse jumps ...<br>
<br>
After some time it _may_ crash. But unfortunately not now :(<br>
<br>
I already use 32-bit userspace (including Cin) on top of x86_64 kernel.<br>
<br>
<br>
> <br>
> 2) Try to run on as powerful as possible one, on many cores, lots of memory,<br>
> high end graphics.<br>
<br>
Well, GG have 128 CPU machine, hopefully this one powerful enough for exposing high end bugs :}<br>
<br>
> <br>
> _______________________________________________________________________________<br>
> <br>
> Georgy Salnikov<br>
> NMR Group<br>
> Novosibirsk Institute of Organic Chemistry<br>
> Lavrentjeva, 9, 630090 Novosibirsk, Russia<br>
> Phone +7-383-3307864<br>
> Email <a href="mailto:sge@nmr.nioch.nsc.ru" target="_blank">sge@nmr.nioch.nsc.ru</a><br>
> _______________________________________________________________________________<br>
> <br>
> <br>
<br>
<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>