LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Maximum Stack Size

Hi All

 

Sorry if this question has been asked and answered before. 

 

I have a application which crashes with a General Protection Fault. I have traced the problem to a realloc call returning NULL, where the application tries to write to the (now) NULL array reference. Is there any reason why a realloc would fail?

 

I managed to get the crash to happen further 'down the line' by increasing the Maximum Stack Size parameter in the Configurations -> Build Options dialog. Is is currently set at 61,457,280 bytes. 

 

However when I try to increase it further, my application does 'funny' things - by this I mean does not behave as when the size is set to 61,457,280 bytes. Is there any reason why increasing the stack size would cause the application to function differently? 

 

The application is 32-bit. The machine I am developing on has 64 GB RAM. I am using CVI 2020.

 

Any assistance on the Maximum Stack Size issue would be appreciated. 

 

Thanks

 

Anand

0 Kudos
Message 1 of 5
(2,062 Views)

realloc does not allocate space on the stack, it uses the heap. When it returns NULL it either means the virtual address space is full or so fragmented that it could not fit the new space in one piece. Check for memory leaks in case memory is full (nearing 4GB usage) or switch to 64-bit compilation if fragmentation is the problem. The stack has pretty little to do with it, except that it also occupies space in the virtual address space. 1 MB is usually enough for the stack.

0 Kudos
Message 2 of 5
(2,043 Views)

Hi MarcelK

 

Thank you for your quick reply.

 

Possibly a silly question, but what is the best way to check for memory leaks. I inherited this application from colleague about 3 years ago. From memory he maintained it for some 12+ years, but I think he inherited from someone before that. While I have been maintaining it, I am quite sure I have been careful in not causing memory issues, but I cannot say if the same is true for all the legacy code. 

 

At the point it crashes, Task Manager reports the application's memory usage is around 2.5 GB - so some way off the 4 GB 32-bit limit. How does this 4 GB limit 'work' - is it for this application alone or for all applications - just wandering why it is crashing when memory usage is only 2.5 GB - or do you think fragmentation is the issue. When reallocing, I the code is requesting 10k more bytes. Is there any clean-up function that can be called to try and help?

 

I did previously try switching to 64-bit, however I am having compilation issues as some parts of the legacy code appears to use 32-bit libraries/functions relating to menu creation. I would really like to update this to remove this dependency, however I do not currently have the time. 

 

Thanks

 

Anand

0 Kudos
Message 3 of 5
(2,025 Views)

Well, 2.5GB of memory usage is a lot because the DLLs and stuff also need space in the virtual address space, so not all can be used for memory allocations. In SysInternal's Process Explorer you can add a column "Virtual size" to check how much of the virtual address space is used up, it might be much nearer the 4GB region.

 

When it comes to fragmentation I like SysInternal's VMMap tool to inspect a process, you could give that one a shot. How big is the piece of memory you want to allocate in total?

 

In terms of leaks, CVI's inbuilt resource tracker is pretty good to track your own memory allocations (Extended debug level or SetEnableResourceTracking function). There is also the CVIDynamicMemoryInfo function that prints some stuff to the debug window.

Message 4 of 5
(2,020 Views)

HI MarcelK

 

Thanks for the info. Yes, I know 2.5 GB is a lot. 

 

In terms of how much I am trying to allocate in total - silly answer, but I am not quite sure as it is a bit dynamic - I did not write this part of the code - it increases as necessary - and to be honest, I don't think it has been written in the most efficient or best way - at a guess probably more than 4 GB, which would be a problem. However I was only looking at Task Manager and seeing 2.5 GB and then wondering why. Your answer of DLLs etc would be the reason. 

 

It has worked for us in the past, however this was when we were attempting to allocate smaller amounts or memory and now that we need to allocate more, it is becoming a problem. 

 

I will try the SysInternal's tools that you suggest, as well as the CVIs resource tracker. 

 

All in all, it looks like I need to write or some how limit what this code is doing. 

 

Thank you again for you help and advise - it is very much appreciated. 

 

Thanks

 

Anand

0 Kudos
Message 5 of 5
(2,016 Views)