On 03/24/2016 09:45 AM, Eric McCorkle wrote:
> Ok, I cracked it.
>
> modules/cpufreq/e_mod_main.c
>
> In _cpufreq_face_update_available
>
> If count is 0, then you get an integer underflow and end up passing a huge
> number to malloc. The code probably ought to check for 0 and do nothing in
> that case.
>
> It looks like there is a little suid program that reads the frequency, and my
> system is set up with nosuid on the lib directory. That's one theory as to
> why this problem emerges with ZFS. I'll try turning off nosuid and see what
> happens.
>
It would probably be helpful if the issue was tracked on a bug report at
phab.enlightenment.org
> On March 23, 2016 5:23:46 PM EDT, Quelrond <quelr...@gmail.com> wrote:
>> To build FreeBSD port with debug symbols:
>>
>> # make WITH_DEBUG=yes
>>
>>
>> That's how I proceeded to get detailed backtrace for phab ticket.
>>
>> Peter
>>
>>
>> On 03/23/2016 19:16, Eric McCorkle wrote:
>>> I couldn't seem to track down where the allocation is happening
>> there. I also couldn't get the freebsd port build to do debug builds.
>>>
>>> I'm going to try good old printf debugging tonight to get to the
>> bottom of it.
>>>
>>> On March 23, 2016 11:50:14 AM EDT, Miguel C <miguelmcl...@gmail.com>
>> wrote:
>>>> On Wed, Mar 23, 2016 at 1:14 PM, Eric McCorkle
>> <e...@metricspace.net>
>>>> wrote:
>>>>
>>>>> A possible root cause: ZFS allows for noexec and nosuid options on
>>>> file
>>>>> systems. I believe the freebsd installer sets them by default, so
>> if
>>>>> you're storing executables in places other than bin/ directories,
>>>> that
>>>>> could be part of the problem.
>>>>>
>>>>>
>>>> True, but that's not the "default" case, exec is set to "on" on all
>> the
>>>> datasets and noexec/nosuid are not present. And if that was the case
>> I
>>>> guess we would see some related error, but what do I know :P
>>>>
>>>> However:
>>>> "Above that is what basically comes down to a trace of freebsd
>> malloc
>>>> for
>>>> an impossibly huge block (size 34359738376). Looks like something
>> in
>>>> e_modapi_save is allocating bad-sized blocks."
>>>>
>>>> maybe e_modapi_save just doesn't do this well for zfs, but just
>>>> guessing,
>>>> I'm not a C coder :|
>>>>
>> ------------------------------------------------------------------------------
>>>> Transform Data into Opportunity.
>>>> Accelerate data analysis in your applications with
>>>> Intel Data Analytics Acceleration Library.
>>>> Click to learn more.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
>>>> _______________________________________________
>>>> enlightenment-users mailing list
>>>> enlightenment-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
>> _______________________________________________
>> enlightenment-users mailing list
>> enlightenment-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
