[oi-dev] FF 43b6 integration

[Мартин Бохниг]

>Пятница, 27 ноября 2015, 12:25 -06:00 от Bob Friesenhahn <bfriesen at simple.dallas.tx.us>:
>
>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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20151128/09710a9f/attachment-0005.html>