>Пятница, 27 ноября 2015, 12:25 -06:00 от Bob Friesenhahn ><[email protected]>: > >On Fri, 27 Nov 2015, Nikola M wrote: > >> On 11/27/15 03:26 PM, Aurélien Larcher wrote: >>> Hi, >>> I vote for integration as there is no critical regression, while on the >>> other side security issues are addressed and broader testing is important. >> >> I need to actually use that not look at it as if it is and curiosity. >> If machine slows to a crawl putting up core dumps and filling the disk with >> 1Gig per closing FF, I would call that as an off reason. > >A simple solution is to change the limit for core file size to zero. >Add this to a script which starts firefox: > >ulimit -c 0 > >Or in C code use setrlimit() with RLIMIT_CORE to set the core file >size limit to zero. > >Make sure that developers with the capability and interest in fixing >the bug can produce useful core dumps. > >Bob Hello, very true. BTW: On my systems I do not have this problem (I wished I had). Because hence (as I don't have it) I cannot fix it. Could somebody pls, upload one such core file to some location? tnx As written in http://openindiana.org/pipermail/oi-dev/2015-November/003860.html I suspect that setting LD_LIBRARY_PATH in my multi-distro gcc/f++ runtime ease-of-use-WhereEverYouAre mini-wrapper causes the scenario. So the easy fix would be to call the exe directly. Last but not least: core's and dumps are not a bug but a feature/service. And who doesn't need or want them can disable their creation system-wide. I won't have a sense of priority nor time to look into this for as long as I have real problems (with invalid vmem offsets in the KMS backport, as quickly scratched on, with many spelling errors as I now see, on http://openindiana.org/pipermail/oi-dev/2015-November/003858.html ) Pls. test if bypassing the wrapper helps. rgds., %martin
_______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
