Memory available in system memory partition suddenly vanishes
Ajay Garg
I am building a system using VxWorks 5.5 with tornado 2.2 on windows.
I am booting target via ethernet. When I run my system, suddenly
system starts giving arror "block too big to allocate". Now to
diagnose this, while system was running on target, I checked the
status of memory from shell on host using memShow(). Here is the
status shown at various instances.
At very beginning just after system comes up on target-
-> memShow
SUMMARY:
status bytes blocks avg block max block
------ ---------- --------- ---------- ----------
current
free 56685480 156 363368 56355556
alloc 2106136 1080 1950 -
cumulative
alloc 2920192 8267 353 -
value = 0 = 0x0
After some time again I did memShow, results are
-> memShow
SUMMARY:
status bytes blocks avg block max block
------ ---------- --------- ---------- ----------
current
free 56680636 158 358738 56355556
alloc 2110980 1095 1927 -
cumulative
alloc 2937960 8301 353 -
value = 0 = 0x0
After few second I did it again
-> memShow
SUMMARY:
status bytes blocks avg block max block
------ ---------- --------- ---------- ----------
current
free 64 3 21 32
alloc 2135160 1169 1826 -
cumulative
alloc 3118952 8469 368 -
value = 0 = 0x0
Here cumulative alloc and alloc is in sync with upper results but free
memory is 64 bytes while it was 56.6MB earlier. I am not able to
understand this behaviour. Has anybody encountered situation like this
earlier too.
Any help is greatly appriciated.
Thanks in advance.
Ajay Garg
Joe Durusau
Not specifically, but this sort of thing is usually caused by
either a stack overflow or be an index that gets to a bad value
and trashes a table somewhere. Try checking the stack first.
Speaking only for myself,
Joe Durusau
Ajay Garg
I have checked the stacks of all tasks spawned through browser. The
stack is not overflown in any case. I am also not able to locate any
bad index scenario as the system behaves very well for sometime
initially. Is there any other tool to locate this type of error.
Regards,
Ajay Garg
rsripathi
There are some tools available to check for memory allocation but
they can hunt for leaks.Unfortunately the vxworks memory manage is not
very easy to debug. I guess it was written for speed and low
consumption (the headers don't occupy much space) and they expected
the user to ensure that everything works correclty. One way to do this
is to run thro your code to see if there are malloc's for large blocks
( I would think you have done this already).
One other way is to use windview and monitor the memory allocation.
The after you hit the "block too big to allocate" message, you can
stop windview and examine which task grabbed the memory or went thro.
malloc.
You can try to set event points at malloc and see which tasks goes
thro. malloc the most. That could indicate something.
These are just pointers based on what is posted.
HTH,
-Kumar
joe durusau
rsripathi wrote:
It doesn't look like malloc is the problem as such. I would first of all try
to see why the cumulative malloc is changing. It really should not, once the system
gets going. I would try investigating any code that is repeatedly calls malloc, as
this may be a weak area.
The only real way to troubleshoot without a lot of luck is to install a 2nd
CPU in the same chassis, set the two of them up so that the 2nd one can see
the memory of the first, and make periodic copies. I suspect sooner or later
you will find a call to malloc or free or some such that is returning an error
but not being checked as such, or you will find a header (the word or two
just before a malloc'd block) that is being trashed by a wild index.
Sorry, not much help, but best I can do.
muralidharan P R
Are you running any applications with the vxWorks. Are you using C++
for the application development?
-Murali.
rsri...@hotmail.com (rsripathi) wrote in message news:<72dddd83.04060...@posting.google.com>...
Lori Fraleigh
Hi Ajay,
If you have a copy of MemScope (part of the ScopeTools package
often sold along with Tornado), you can use it to see who allocs
memory and the HeapCheck utility to check the consistency of the
heap data structures. The latter may help you narrow down if
anyone is randomly writing into the heap and corrupting the data
structures.
Regards,
Lori
--
Lori Fraleigh Director, ScopeTools Business Unit
Real-Time Innovations, Inc. http://www.rti.com
Phone: 408-734-4200 x121 Fax: 408-734-5009
> _______________________________________________
> VxWorks Users Group mailing list
> VxWe...@lbl.gov
> http://www-csg.lbl.gov/vxworks/
>
Ajay Garg
Yes, I am using c++ for application development and I am running this
application on VxWorks 5.5. As far as cumulative malloc is concerned,
i think it is suppose to change as I making certain new objects. But
there might be possibility of a leak. But this should not reduce the
memory size to few bits in a moment. Moreover the lost memory is not
shown in allocated memeory. I am not able to figure out where that
memory has gone. Are some of partition header is getting corrupted,
because of which OS is not able to print correct details.
Moreover, I do not have tools loke windview and memscope as ther are
part of tornado professional while I have tornado standard.
Thanks,
Ajay Garg.
mura...@ctd.hcltech.com (muralidharan P R) wrote in message news:<d2e22f5.04060...@posting.google.com>...
Robert Lawrence
was related to "nilrep" and the use of basic_string() (or C++ string
classes) which are not threadsafe in all versions of the compiler. It seems
that the template gets a huge length, then when a string object is
allocated, it does exactly what you are seeing.
Hope this helps.
"Ajay Garg" <hi_...@yahoo.com> wrote in message
news:f9cc3bc5.04060...@posting.google.com...