On 05/10/2016 08:55 PM, Vlad Khorsun wrote:
> 10.05.2016 20:23, Alex Peshkoff wrote:
>> On 05/10/2016 07:54 PM, Dimitry Sibiryakov wrote:
>>> 10.05.2016 18:22, Alex Peshkoff wrote:
I think that for 32-bit systems it's time to change limit to 256Kb, for
64 - to 512Kb.
>>> Max page si
10.05.2016 20:23, Alex Peshkoff wrote:
> On 05/10/2016 07:54 PM, Dimitry Sibiryakov wrote:
>> 10.05.2016 18:22, Alex Peshkoff wrote:
>>> I think that for 32-bit systems it's time to change limit to 256Kb, for
>>> 64 - to 512Kb.
>> Max page size doesn't depend on bitness. Thus there is no point
10.05.2016 20:38, Dimitry Sibiryakov wrote:
>
> May be you just didn't try to build debug build after Dmitry committed the
> bigger page?..
I surely built it successfully (64-bit Linux, Debug) before committing.
Dmitry
--
10.05.2016 17:49, Dimitry Sibiryakov wrote:
>
> It looks like variable "temporary_key keys[MAX_LEVELS];" has size more than
> 128kb.
IMO, a proper solution would be to avoid such huge stack allocations.
Either temporary key or array (or both) could grow dynamically, if
required. I will take a l
10.05.2016 19:23, Alex Peshkoff wrote:
> builtin_frame_address() is not looking good at the first glance.
> A message about it saying "Calling this function with a nonzero argument can
> have unpredictable effects, including crashing the calling program" does not
> provide big desire to use it (a
On 05/10/2016 07:54 PM, Dimitry Sibiryakov wrote:
> 10.05.2016 18:22, Alex Peshkoff wrote:
>> I think that for 32-bit systems it's time to change limit to 256Kb, for
>> 64 - to 512Kb.
> Max page size doesn't depend on bitness. Thus there is no point to have
> different limit.
I talk not only
10.05.2016 18:22, Alex Peshkoff wrote:
> I think that for 32-bit systems it's time to change limit to 256Kb, for
> 64 - to 512Kb.
Max page size doesn't depend on bitness. Thus there is no point to have
different limit.
I'd suggest to try
https://msdn.microsoft.com/en-us/library/windows/des
On 05/10/2016 06:53 PM, Dimitry Sibiryakov wrote:
> 10.05.2016 17:43, Alex Peshkoff wrote:
>> What exact digits do you get in ProbeStack() for myStack and thisLocation?
> thisLocation = 0x00132018
> myStack = 0x00111574
>
> But increasing this for a couple of kilobytes will only
10.05.2016 17:43, Alex Peshkoff wrote:
> What exact digits do you get in ProbeStack() for myStack and thisLocation?
thisLocation = 0x00132018
myStack = 0x00111574
But increasing this for a couple of kilobytes will only put the problem off.
This
procedure has much more local v
On 05/10/2016 05:49 PM, Dimitry Sibiryakov wrote:
> 10.05.2016 15:55, Dimitry Sibiryakov wrote:
>> Any idea what's wrong with these lines?
> It looks like variable "temporary_key keys[MAX_LEVELS];" has size more
> than 128kb.
>
What exact digits do you get in ProbeStack() for myStack and
10.05.2016 15:55, Dimitry Sibiryakov wrote:
> Any idea what's wrong with these lines?
It looks like variable "temporary_key keys[MAX_LEVELS];" has size more than
128kb.
--
WBR, SD.
--
Mobile security can be e
Hello, All.
Debug build of current HEAD on Win64 fails with following stack trace.
> msvcr120d.dll!07f904db7642()Unknown
> msvcr120d.dll!07f904ee2044()Unknown
> engine12.dll!fb_assert_impl(const char * msg, const char * file, int
> line, bool do_ab
12 matches
Mail list logo