You're right, if I divide the stack size by 2 then it's fine. I never would have imagined the stack limit to be so low under Windows.

So my problem is most likely in OpenCV then.

But there's still the issue where a user would like to use a more efficient thread-local or allocation rate based allocator.

--
 
Phil Bouchard 
CTO
T: (819) 328-4743
E: phil_at_[hidden] | www.fornux.com
1188 rue Saint-Louis | Gatineau (Qc), J8T 2L8 Canada
Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire.
This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
> On Feb 19, 2023, at 12:06 AM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
> 
> ---------- Forwarded message ---------
> From: Jason McKesson <jmckesson_at_[hidden]>
> Date: Sun, Feb 19, 2023 at 12:05 AM
> Subject: Re: [std-proposals] set_new_handler extension
> To: Phil Bouchard <boost_at_[hidden]>
> 
> 
>> On Sat, Feb 18, 2023 at 11:39 PM Phil Bouchard <boost_at_[hidden]> wrote:
>> 
>> 
>> 
>>> On 2/17/23 12:07, Jason McKesson via Std-Proposals wrote:
>>> You realize that this proves precisely nothing, right? The source of
>>> the bug could still be in your code. Switching memory allocators means
>>> switching where the heap tracking stuff is (and a GPU allocator
>>> probably puts heap tracking in your CPU's memory rather than GPU
>>> memory of which there is far less). So a wild-write which on one
>>> allocator hits heap tracking data, would very likely miss heap
>>> tracking data on a different allocator. It would hit something else,
>>> something that your program is able to tolerate better.
>> 
>> Alright I forgot my laptop is dual-boot with Windows 8.1. So I compiled
>> the application attached using clang++ version 8.0 under Windows and
>> clang++ version 10.0 under Linux on the *same* laptop of 16 GB of memory.
>> 
>> On Windows, it crashes before printing anything.
>> 
>> On Linux, it works perfectly fine  and outputs:
>> 
>> int main(): allocating maximum: 65536 kilobytes.
>> void test(int): 1
>> void test(int): 2
>> void test(int): 4
>> void test(int): 8
>> void test(int): 16
>> void test(int): 32
>> void test(int): 64
>> void test(int): 128
>> int main(): done.
>> 
>> So case closed, I proved my point. The only hope left is to amend the C++ standards.
> 
> To amend it to do... what? Fix your *stack overflow*? Because that's
> what the Visual Studio debugger told me happened when you stuck a 2MB
> array on the stack.
> 
> Once I took out your massive stack allocation... it ran fine.
> 
> But you are right. The case of Phil Brouchard v Bias against Microsoft
> has been closed. You are guilty.
> -- 
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals