Ошибка r6016 microsoft visual

Ошибка времени выполнения C R6016

недостаточно памяти для данных потока

Если при запуске приложения возникло это сообщение об ошибке, работа приложения была завершена из-за внутренней проблемы с памятью. Существует множество возможных причин возникновения этой ошибки, но часто это вызвано крайне нехваткой памяти, ошибкой в приложении или ошибкой в надстройке или расширении, используемом приложением.

Для устранения этой ошибки попробуйте выполнить следующие действия:

• Закройте другие запущенные приложения или перезагрузите компьютер, чтобы освободить память.
• используйте страницу приложения и компоненты или программы и компоненты в панель управления , чтобы восстановить или переустановить приложение.
• используйте страницу приложения и компоненты или программы и компоненты в панель управления , чтобы удалить, восстановить или переустановить надстройки или расширения, используемые приложением.
• проверьте клиентский компонент Центра обновления Windows в панель управления для обновлений программного обеспечения.
• Проверьте наличие обновленной версии приложения. Если проблема не исчезнет, обратитесь к поставщику приложения.

Сведения для программистов

Эта ошибка возникает из-за того, что программа не получила достаточно памяти операционной системе для завершения _beginthread или _beginthreadex вызова, либо локальное хранилище потока не было инициализировано _beginthread или _beginthreadex .

Для создаваемого потока в библиотеке должна создаваться внутренняя база данных. Если выделяемой в операционной системе памяти недостаточно для расширения базы данных, поток не запускается, а вызывающий процесс останавливается. Это может произойти, если процесс создал слишком много потоков или если локальное хранилище потока полностью заполнено.

рекомендуется, чтобы исполняемый файл, вызывающий библиотеку времени выполнения C (CRT), использовался _beginthreadex для создания потоков, а не для Windows API CreateThread . _beginthreadex инициализирует внутреннее статическое хранилище, которое используется многими функциями CRT в локальном хранилище потока. Если поток создан с помощью функции CreateThread , среда CRT может завершить процесс с ошибкой R6016 в случае вызова функции CRT, для которой требуется инициализированное внутреннее статическое хранилище.

Источник

C Runtime Error R6016

not enough space for thread data

If you encounter this error message while running an app, the app was shut down because it has an internal memory problem. There are many possible reasons for this error, but often it’s caused by an extremely low memory condition, a bug in the app, or by a bug in an add-in or extension used by the app.

You can try these steps to fix this error:

• Close other running applications or restart your computer to free up memory.
• Use the Apps and Features or Programs and Features page in the Control Panel to repair or reinstall the app.
• Use the Apps and Features or Programs and Features page in the Control Panel to remove, repair or reinstall add-ins or extensions used by the app.
• Check Windows Update in the Control Panel for software updates.
• Check for an updated version of the app. Contact the app vendor if the problem persists.

Information for Programmers

This error occurs because the program did not receive enough memory from the operating system to complete a _beginthread or _beginthreadex call, or thread local storage has not been initialized by _beginthread or _beginthreadex .

When a new thread is started, the library must create an internal database for the thread. If the database cannot be expanded by using memory provided by the operating system, the thread does not begin and the calling process stops. This can happen when too many threads have been created by the process, or if thread local storage has been exhausted.

We recommend that an executable that calls the C runtime library (CRT) should use _beginthreadex for thread creation rather than the Windows API CreateThread . _beginthreadex initializes internal static storage used by many CRT functions in thread local storage. If you use CreateThread to create a thread, the CRT may terminate the process with R6016 when a call is made to a CRT function that requires initialized internal static storage.

Источник

C runtime library error r6016

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

My statically-linked Visual C++ 2012 program sporadically generates a CRTL error: «R6016 — Not enough space for thread data».

Microsoft documentation says this error message is generated when a new thread is spawned, but not enough memory can be allocated for it.

However, my code only explicitly spawns a new thread in a couple of well-defined cases, neither of which are occurring here (although certainly the Microsoft libraries internally spawn threads at will). One user reported this problem when the program was just existing in the background.

Not sure if it’s relevant, but I haven’t overridden the default 1MB reserved stack size or heap size, and the total memory in use by my program is usually quite small (3MB-10MB on a system with 12GB actual RAM, over half of which is unallocated).

This happens very rarely (so I can’t track it down), and it’s been reported on more than one machine. I’ve only heard about this on Windows 8.1, but I wouldn’t read too much into that.

Is there some compiler setting somewhere that might influence this error? Or programming mistake?

Answers

«JDWeng, I agree with everything you just said»

Except that what he says has little to do with your problem.

«The error you are getting is caused by an access to a memory location outside the bounds that the operating system is allowing and causing an exception. So any type error that accesses a invalid memory error can be causing this problem.»

Oh well, that sounds like the description of an access violation exception. Too bad that the error you are seeing has nothing to do with access violation or any other exception.

R6016 is a error generated by the VC runtime. The source of the C runtime is included with Visual Studio (check the VS installation folderVCcrtsrc). That means you could take a look at it and get an idea about what’s going on. Here’s what I found after a quick look:

1. This error can occur during app startup when the (non dll) C runtime is initialized. This seems to match your situation because you statically link the C runtime.

But this initialization occurs before your code gets a chance to run and the possible reasons for this include lack of memory and lack of TLS slots. I’m not sure how that can happen during at app startup, that would mean that the system itself is toast.

2. This error can also happen when you create a thread by using CreateThread or any other function which doesn’t use _beginthtread/_beginthreadex. To be precise, you won’t get this error when the thread is created, you’ll get this error later when you try to access some CRT functionality which requires a per thread data structure.

The typical reason for failure in this situation is lack of memory but that thread data structure is 100-200 bytes in size, I find it hard to believe that exactly this allocation fails, surely there are other allocations of roughly the same size in your program.

Another reason could be failure of TlsSetValue caused by memory corruption but this seems unlikely too, you would have to be terrible unlucky to corrupt exactly the memory used by the TLS storage.

So, do you at least know what this error occurs? Does it happen during application startup or later?

It has nothing to do with the stack either.

Here are 2 ways to reproduce R6016:

This one simply «corrupts» the CRT’s __flsindex variable, this will prevent the runtime from retrieving the per thread data even if the data was already allocated.

This one uses CreatedThread and exhausts all the heap memory before calling strtok — you get R6016 because the runtime cannot allocate memory for the per thread data.

Note that in both cases the executable must be linked statically to the VC runtime. __flsindex isn’t accessible if you’re using the dll runtime so the first approach fails to link. The dll runtime relies on DLL_THREAD_ATTACH notifications to allocate the per thread data and it’s more likely that thread creation will simply fail than to get R6016.

Both situations are possible in practice but it seems to me that you’d have to be quite unlucky for the outcome of memory corruption or lack of memory to be this R6016 error.

PS: Anyone who wants to try the second example should run the release build and should not run it in the debugger. Doing otherwise might cause your system to lockup for some time due to excessive paging.

See also kb118816 about possible reasons of TLS allocation failures, although it also refers to win32s. IIRC, even if one believes that a VC++2012 app is linked statically, there are some DLLs involved in runtime, nevertheless.

To get the latest VC++ library, look here.

Usually these type error messages are generic and you shouldn’t interprete them literally. It is an error message indicating an invalid pointer. It is possible that you didn’t allocate enough memory or one of your pointer exceeded the memory allocated. Somethimes these errors occur because a point exceeded the memory allocated by a few bytes. You may also have a memory leak.

Check to make sure pointers are the same size as the variables they are pointing to. If you have a byte array, don’t use a pointer that is point to an integer that increments by 4 or 8 bytes at a time.

Are you confident that the error is being reported «incorrectly», or is it possible that this really is what it says? Is there anything else I could check?

It would be an amazingly difficult task to try to go through the entire program to exhaustively check that all use of memory is without flaw (every C++ programmer’s nightmare!). Wouldn’t be so bad if we had a repeatable case.

We do use _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ), so I’m «reasonably» confident we don’t have a memory leak, but a leak wouldn’t cause an invalid pointer anyway.

40 years, eh? Well, that beats my 30!

I guess I’ll just have to wait and try to see if I can catch it in the act, or notice some kind of pattern, because a grounds-up review of the entire program is simply not practical.

I am curious, though: how can a memory leak cause an invalid memory access? I define a memory leak as forgetting to free something that is no longer referenced. In any case, we’ve taken decent precautions against those, and have immediately eradicated any that are detected.

Please check if the solutions in the following links could work for you:

We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click HERE to participate the survey.

Thanks, Jane. I had previously seen those articles, but I discounted them because:

• The first one is about win32s, and I am running modern programs on Windows 8.1. Furthermore, it talks about spawning an app 60 times, and this is not a spawn problem and the app was only launched a few times.
• The second one talks about a corrupted/repaired DLL, and we are using static linking.

I suppose it’s possible that the libcmt.lib on the developer machine could have become corrupted (although I think that may be grasping at straws at my end).

I don’t have an MSDN subscription: what’s the best way to get the most recent version of libcmt.lib that I should be using with Visual Studio 2012. I see that ours is dated 11/5/2012; I would have thought that some maintenance release would have updated this.

I don’t have an MSDN subscription: what’s the best way to get the most recent version of libcmt.lib that I should be using with Visual Studio 2012. I see that ours is dated 11/5/2012; I would have thought that some maintenance release would have updated this.

Thanks for your feedback.

If you have any suggestions on updating Visual Studio products with C++, please consider reporting them on the following site:

We would appreciate the contribution you made to this forum.

We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click HERE to participate the survey.

Pavel, thanks for trying to help! You are correct that even a statically linked program makes calls to the OS and ultimately its DLLs, but that’s not relevant here. I do not distribute any DLLs with the program, so downloading resdistributable DLLs to my development computer isn’t going to help my users.

I was just hoping that someone else had actually encountered this error, knew what it meant, and solved it by some easy fix (e.g., «Just set the stack size to 2MB!»). So far, I’ve basically just heard that I should disregard what the error says and make sure my use of memory is pristine. Could be correct, but without a repeatable test case, it’s a daunting/impossible task to try prove all use of memory is correct in all cases. I suppose I could purchase some version of BoundsChecker to help with this, although frankly Visual Studio itself has done a decent job of warning us when we overstep.

JDWeng, I agree with everything you just said, and have had to root out difficult problems before . but it’s difficult to invest the time to try to do a top-to-bottom review of all possible memory use when the only symptom is an intermittent/very rare error message from another package (is our program even to blame, or are there other things going on in the OS that are triggering this?). You have indicated a belief that it’s probably due to some kind of memory overwriting on our program’s part, but I sure wish I had something firmer to go on before embarking on a task that can probably never be proven correct (that all memory usage is legal). Oh well, maybe I’ll get lucky and we’ll run into something repeatable.

I do wish that someone from inside Microsoft would weigh in here and tell us what can actually cause this error message.

«JDWeng, I agree with everything you just said»

Except that what he says has little to do with your problem.

«The error you are getting is caused by an access to a memory location outside the bounds that the operating system is allowing and causing an exception. So any type error that accesses a invalid memory error can be causing this problem.»

Oh well, that sounds like the description of an access violation exception. Too bad that the error you are seeing has nothing to do with access violation or any other exception.

R6016 is a error generated by the VC runtime. The source of the C runtime is included with Visual Studio (check the VS installation folderVCcrtsrc). That means you could take a look at it and get an idea about what’s going on. Here’s what I found after a quick look:

1. This error can occur during app startup when the (non dll) C runtime is initialized. This seems to match your situation because you statically link the C runtime.

But this initialization occurs before your code gets a chance to run and the possible reasons for this include lack of memory and lack of TLS slots. I’m not sure how that can happen during at app startup, that would mean that the system itself is toast.

2. This error can also happen when you create a thread by using CreateThread or any other function which doesn’t use _beginthtread/_beginthreadex. To be precise, you won’t get this error when the thread is created, you’ll get this error later when you try to access some CRT functionality which requires a per thread data structure.

The typical reason for failure in this situation is lack of memory but that thread data structure is 100-200 bytes in size, I find it hard to believe that exactly this allocation fails, surely there are other allocations of roughly the same size in your program.

Another reason could be failure of TlsSetValue caused by memory corruption but this seems unlikely too, you would have to be terrible unlucky to corrupt exactly the memory used by the TLS storage.

So, do you at least know what this error occurs? Does it happen during application startup or later?

Mike, that’s very helpful!

The problem occurs long after app startup (hours?). There are only 2 places we explicitly call CreateThread, but since they weren’t being called at the time of error, I didn’t see how they were relevant.

Given your explanation that they could cause problems to subsequent CRT internal threads, I noticed that one is not supposed to use CreateThread for programs which use the CRT, and instead one is supposed to use _beginthreadex (as you reference above). Oops!

I have replaced both calls to CreateThread and will update this forum if I ever hear of the R6016 error occurring again. However, I’m not completely confident that this will solve the issue, as it’s not clear that these CreateThread calls were ever triggered before the error was encountered. Regardless, it’s worth correcting.

«we explicitly call CreateThread, but since they weren’t being called at the time of error, I didn’t see how they were relevant.»

The problem is that the error will never occur when you call CreateThread, it will occur later, when you call a C function which needs the per thread data. For example strtok needs this, it keeps its state per thread. If the per thread data wasn’t already allocated then the runtime must allocate the data and store it in a TLS slot. If memory allocation fails or TlsSetValue then kboom, R6016 because there’s nothing the runtime can do about it, strtok and other CRT functions don’t have any means to return an error to the caller.

_beginthreadex is supposed to avoid such failures by pre allocating the per thread data before the thread starts, if the allocation fails then _beginthreadex simply returns 0 (be sure to check for that) instead of terminating the program with R6016.

«and instead one is supposed to use _beginthreadex (as you reference above). Oops!»

Yeah, though that the documentation needs to be taken with a grain of salt in this regard. It’s one of those «just in case» things, there are all kinds of situation where _beginthreadex simply isn’t an option.

Mike: I’m not not sure I understand you answer. I would like to know more about your justifications and not disagreeing with your answer. Again we are talking about grains of sand

I have a wide interpretation of memory leaks. I also understand the micoprocessor exceptions especially the protection that was first added in te 80286/80386 processor which causes the run time exception. I also wish that microsoft doesn’t event their own terminolgy that intel developed for the x86 processors.

When Intel enhanced the 8086 archetecture they changed the segment register to sector registers by increasing the number of bits and then adding in these additional bits range limits to cause exceptions if a program went outside these limits. Microsoft took the Intel’s protection scheme and called it TLS.

With the Intel archetecture you can get two types of run time exceptions.

1) If you attempt to access a sector not allocated to the program

2) You access a sector that is assigned to your thread, but exceeds the lower or upper range of the sector register.

I don’t know how Microsoft interpretes these two hardware exceptions. I know in most cases you usually get an exception starting with 0x8 when exceptions like this occurs but don’t know how microsoft maps the hardward exception to the error messages that are produced and would like to know more about this if you can supply me and documentation.

«Mike: I’m not not sure I understand you answer.»

Ha ha, then we’re even. I don’t understand a thing from your posts either.

Exception? What exception, I already explained that R6016 isn’t an exception. It’s simply a fatal error generated by the VC runtime in very particular situations. If you don’t believe me feel free to look at the VC runtime source. I don’t know what else I can add here about R6016, I’ve already written enough.

And in general, you’re just making a mess of it:

«When Intel enhanced the 8086 archetecture they changed the segment register to sector registers»

There’s no such thing as «sector register» in the Intel architecture. Probably you mean selectors, not sectors.

«adding in these additional bits range limits to cause exceptions if a program went outside these limits»

Yeah, selectors (well, segment descriptors to be precise) do have limits. But exceeding those limits generates a SEH exception, not R6016. And it’s almost impossible to exceed those limits on Windows because the default limit for the code and data selectors is 4 GB.

«Microsoft took the Intel’s protection scheme and called it TLS.»

TLS = thread local storage — well know name for a well known feature that has nothing to do with memory protection.

«1) If you attempt to access a sector not allocated to the program»

This time you probably mean page, not sector.

«2) You access a sector that is assigned to your thread, but exceeds the lower or upper range of the sector register. «

Neither pages nor selectors are assigned to threads, they’re assigned to processes.

«I know in most cases you usually get an exception starting with 0x8 when exceptions «

You probably mean 0xC, not 0x8. For example accessing a page that hasn’t been allocated to your process results in a SEH exception which has the exception code = STATUS_ACCESS_VIOLATION = 0xC0000005.

But again, R6016 is not an exception, is not produced by the hardware nor the operating system.

It has nothing to do with the stack either.

Here are 2 ways to reproduce R6016:

This one simply «corrupts» the CRT’s __flsindex variable, this will prevent the runtime from retrieving the per thread data even if the data was already allocated.

This one uses CreatedThread and exhausts all the heap memory before calling strtok — you get R6016 because the runtime cannot allocate memory for the per thread data.

Note that in both cases the executable must be linked statically to the VC runtime. __flsindex isn’t accessible if you’re using the dll runtime so the first approach fails to link. The dll runtime relies on DLL_THREAD_ATTACH notifications to allocate the per thread data and it’s more likely that thread creation will simply fail than to get R6016.

Both situations are possible in practice but it seems to me that you’d have to be quite unlucky for the outcome of memory corruption or lack of memory to be this R6016 error.

PS: Anyone who wants to try the second example should run the release build and should not run it in the debugger. Doing otherwise might cause your system to lockup for some time due to excessive paging.

R6016 Runtime error, Microsoft Visual C++ Runtime Library

I have a solution. At least it works for me. I am running Windows 10 Pro 64 bit. I was getting this error message every day on a very random basis, but consistently every day, all day.

The R6016 Error message has to do with thread data and the lack of space available for these threads. Not real sure about the technical specifics, nor will I pretend to understand how all this works, but I can, on the surface plow my way through the global view and show my approach to this resolution.

Here’s what I did:

On the task bar, at the bottom of the screen, right click on an empty area of the task bar and choose the «Task Manager» (Mine is third entry from bottom of list). Then left click the «Performance» tab. Towards the bottom of that screen you will see several different ‘Counts’, one of which is ‘Threads’. That is the thread count the error message is referring to. My thread count was usually around 1300, 1400 as high as 1500 sometimes and this is about the time I was getting the R6016 error messages. If I walked away from the PC for any length of time the R6016 error messages would stack up and I would have as many as 12 or more error messages to respond to in order to get rid of them.

So, on the right side of the task bar there are several icons that reflect applications that are running currently on your system. That is to say they are occupying memory and processor and are executing on your PC. Each of these processes require threads in order to run. I suspect they require many threads to start, stop, move in and out of memory, are subject to paging, etc. You may have as many as 15 or more of these processes on the task bar. I had 19 of these icons on the right side of my task bar. I managed to get rid of about 7 of them by usually right clicking the icon and getting into the preferences for that application and removing the check box that starts the app at boot time.

As a result, the number of thread counts in the Task Manager went from 1400 or 1500 to about 1000 or less. I no longer get that R6016 Error message. I haven’t seen that error message for more than two weeks now. I will occasionally check the Task Manager for the thread count and it varies from about 900 to 1100 every day all day.

Not real sure how this approach would work with other operating systems but for Win 10 64 bit it seems to be the solution.

Источник