[Live-devel] setlocale 0xc0000374 heap corruption - LOCALE_NOT_USED is OK

[Jonathan Brady]

Hello,

After spending 10 seconds googling "setlocale crash" I can inform you that:

  * On Windows setlocale is not thread safe
      o https://social.msdn.microsoft.com/Forums/windowsserver/en-US/b46aa226-d337-43c3-8d15-135f6fca9b53/setlocale-behavior-in-multithreaded-applications?forum=vcgeneral
  * It hasn't been thread safe since Visual C++ 2012.
      o https://www.tolon.co.uk/2014/10/beware-setlocale/

Regards,

Jonathan


On 26/10/2021 16:22, Richard Lince wrote:
> Hi Ross,
>
> Yes, very familiar with the FAQs, we certainly fall into this category 
> during the single process test:
>
> "Another possible way to access the code from multiple threads is to 
> have each thread use its own "UsageEnvironment" and "TaskScheduler" 
> objects, and thus its own event loop. The objects created by each 
> thread (i.e., using its own "UsageEnvironment") must not interact 
> (except via global variables). Such a configuration is not 
> recommended, however; instead, it is safer to structure such an 
> application as multiple /processes/, not multiple threads. "
>
> Not using any static variables, all code remains class based our side. 
> Each RTSPClient has its own thread for the event loop and we invoke on 
> another dedicated thread ourside for invoking response handlers. 
> Simply put, if we define *LOCALE_NOT_USED *we can stream 96+ instances 
> (each with its own environment, task scheduler & set of event 
> triggers) within a single process.
>
> It was strange to see the 'setlocale' being the issue and wondered if 
> you had any idea or seen this before?
> Are we perhaps calling 'setlocale' to often and abusing it somehow, 
> it's called quite often..?
>
> Thanks!
>
> *
> *
> On 26/10/2021 14:21, Ross Finlayson wrote:
>> I didn’t really follow this.  However, I was disturbed by the following:
>>
>>> By default the NEWLOCALE_NOT_USED is defined and works great when we run up many streaming windows all in separate process's.
>>> If we use a single process (less memory consumed by NVIDIA graphics) we see an access violation
>> I hope you are not running more than one thread in "a single process” - because this is not allowed.  LIVE555 code (within a single process) is meant to run as a single thread, using a (single-threaded) event loop for concurrency.  Seehttp://live555.com/liveMedia/faq.html#threads
>>
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>>
>>
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>
> Best Regards,
> Richard Lince,
> Founder & Managing Director
>
> bluebox.video <https://www.bluebox.video>
> +44(0)7841665146
>
> logo
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20211026/384acabc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_email.png
Type: image/png
Size: 6840 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20211026/384acabc/attachment-0001.png>