LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

CmtScheduleThreadPoolFunction error: -14910 System error occurred.

In Labwindows/CVI 7.0 CmtScheduleThreadPoolFunction would always generate this error. Just happened to try increasing the max stack size in Build Options to about 64MB and now randomly getting the system error occurred from the CmtScheduleThreadPoolFunction. Increased the max stack size some more to see if that would fix it, but the CmtScheduleThreadPoolFunction would just always error. Is there an ideal max stack size to use when dealing with threads? Or is there something else I should be looking at due to this Error -14910 System error occurred from the CmtScheduleThreadPoolFunction? Thanks in advance
0 Kudos
Message 1 of 10
(5,058 Views)

Can you post the parts in your code where you create the thread pool, define the thread function and the line that generates the error.

 

Can't the CVI library generate an error string for this error code?

S. Eren BALCI
IMESTEK
0 Kudos
Message 2 of 10
(5,034 Views)

The default stack size for Windows threads is 1 Mbyte. If you need more than this maybe you should use a different progamming approach; for example making more use of the heap.

 

JR

0 Kudos
Message 3 of 10
(5,018 Views)

/* create new thread pool and set max thread number */
status = CmtNewThreadPool (10, &pool_handle);

// Schedule a thread functions
status = CmtScheduleThreadPoolFunction (pool_handle, thread_function, (int *)thread_function_data, NULL); // it is giving me the error here.


***************************************************

static int CVICALLBACK thread_function (void *functionData)
{
int test;
test = (int)functionData;
switch (test)
{
case 1:
test_1;
break;
case 2:
test_2;
break;
}
return 0;
}

0 Kudos
Message 4 of 10
(5,006 Views)
Do the shipping CVI threadpool samples run fine, or do they also return this error? These samples would be in cvi/samples/utility/threading/ThreadPool.
0 Kudos
Message 5 of 10
(4,993 Views)

Can you try this:

 

status = CmtScheduleThreadPoolFunction (pool_handle, thread_function, thread_function_data, NULL); // "(int *)" deleted


static int CVICALLBACK thread_function (void *functionData) 

int test; 
test = *((int*)functionData)

...
}

S. Eren BALCI
IMESTEK
0 Kudos
Message 6 of 10
(4,976 Views)

Thanks for the help, but still no luck. In the debug configuration it game me a little bit more information.

Library function error (return value -- -14910).

Not enough storage is available to process this command.

 

is this a hard disk storage? the machine has plenty of disk space free 50+ GB. memory? thread stack size maybe? currently its whatever the defualt is. anyone know

0 Kudos
Message 7 of 10
(4,939 Views)

To re-ask Mohan's question: Do the shipping CVI threadpool samples run fine, or do they also return this error? These samples would be in cvi/samples/utility/threading/ThreadPool.

 

We need this information to help you further. 


Mark E.
National Instruments

0 Kudos
Message 8 of 10
(4,894 Views)
The thread examples that shipped with CVI do work.

Added some CmtGetThreadPoolAttribute calls before the CmtScheduleThreadPoolFunction call in order to see what was going on.

Found out that I could schedule 4 threads just fine, but on the 5th thread, this is when it would error.

I also tried to preallocate a pool of 10 threads before the CmtScheduleThreadPoolFunction call using CmtPreAllocThreadPoolThreads.

    1. At the beginning, CmtGetThreadPoolAttribute for ATTR_TP_NUM_THREADS returned 0. (expected)
    2. CmtPreAllocThreadPoolThreads for 10 threads (number_ofThreadsCreated returned unexpected large integer value, expected 10)
    3. CmtGetThreadPoolAttribute for ATTR_TP_NUM_THREADS returned 4. (expected 10).
   
This lead me to believe that I could not schedule more than 4 threads with what I have currently.

Dont know how this relates, but in the build options, I reduced the max stack size from 64000000 bytes to 32000000 bytes. (which later gave me some General Protection Fault errors?)
And debugged the application again with the only change being the max stack size in the build option.

    1. At the beginning, CmtGetThreadPoolAttribute for ATTR_TP_NUM_THREADS returned 0. (expected)
    2. CmtPreAllocThreadPoolThreads for 10 threads (number_ofThreadsCreated returned 10, expected)
    3. CmtGetThreadPoolAttribute for ATTR_TP_NUM_THREADS returned 10. (expected)
   
I could now schedule more than 4 threads! Changing this max stack size seemed to fix that problem, but gave me a new one (General Protection Fault)

What does this max stack size in the build option have to do with the threads?

Is there a way to find out the size needed for a thread?

Does it also have something to do with General Protection Fault error?

Is there a document, pdf, or manual with more information about threads and the build options (max stack size)?

Appreciate all the input.
Message Edited by tommyH on 05-06-2009 12:54 PM
0 Kudos
Message 9 of 10
(4,869 Views)
The memory for the stack has to be allocated when a thread is created. If the system cannot allocate the thread's stack, then the thread creation will fail. The stack sizes you are using seem to be really large (32-64MB). You should try to find out why the GPF is happening. The fact that it does not happen for larger stack size indicates that it may be because of stack overflow or corruption. This may be due to some long recursion taking place and busting the stack. Or you may have very large local variables - you could try making them global or using heap memory (malloc) for such variables. Running the debug version may also help find the GPF.
0 Kudos
Message 10 of 10
(4,849 Views)