<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>App crashes without unused array declaration</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/27462/app-crashes-without-unused-array-declaration</link><description> 
I have an application that is running on an ARM9 and compiled with
V3.60. It uses RL. I am having a strange problem. We are really close
to the maximum amount of memory on our processor, within 2K. During
development, I declared an unsigned char array</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: App crashes without unused array declaration</title><link>https://community.arm.com/thread/116218?ContentTypeID=1</link><pubDate>Thu, 27 Jan 2011 05:27:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0d5f1d58-c9d7-4fe5-9cc3-a90675c07be0</guid><dc:creator>Robert Trabue</dc:creator><description>&lt;p&gt;&lt;p&gt;
Not exactly, no. I plan to discuss ways to correct the root cause
with our Manager of Software Development to make sure it is fully
resolved.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: App crashes without unused array declaration</title><link>https://community.arm.com/thread/104545?ContentTypeID=1</link><pubDate>Wed, 26 Jan 2011 21:25:37 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f42e8448-9b78-46a9-bcbc-37b571c3587d</guid><dc:creator>Tamiryan Michael</dc:creator><description>&lt;p&gt;&lt;p&gt;
It&amp;#39;s hard to tell without seeing the code, but it sounds as if the
&lt;b&gt;root cause&lt;/b&gt; is still there! Are you comfortable with a buffer
overrun solved by a different timing...?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: App crashes without unused array declaration</title><link>https://community.arm.com/thread/78982?ContentTypeID=1</link><pubDate>Wed, 26 Jan 2011 15:11:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7582aec3-29eb-4dd7-bdf8-826538251aa4</guid><dc:creator>Robert Trabue</dc:creator><description>&lt;p&gt;&lt;p&gt;
Well, I think I&amp;#39;ve figured it out. I&amp;#39;ll explain so that maybe this
helps someone.&lt;/p&gt;

&lt;p&gt;
The next line after the Mem_Write call was:&lt;br /&gt;
os_dly_wait(30);&lt;/p&gt;

&lt;p&gt;
I commented that out too. If I uncommented only the os_dly_wait
line, crashes occured again, whereas uncommenting Mem_Write and
leaving os_dly_wait commented did not. What I think was happening is
that the os_dly_wait call combined with a debug message that I was
sending on the same interface and the response back to the sender
were stacking up too much stuff, causing a stack overflow. The debug
message and the response to the sender both use static arrays, but
they have to control an OS_MUT with an infinite timeout to be sent.
Removing the delay allowed the debug message and response to go out
without a delay, thus preventing the overflow.&lt;/p&gt;

&lt;p&gt;
So it was a combination of stack overflow and task switching that
caused a crash, followed by a watchdog reset.&lt;/p&gt;

&lt;p&gt;
Thanks all.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: App crashes without unused array declaration</title><link>https://community.arm.com/thread/59112?ContentTypeID=1</link><pubDate>Wed, 26 Jan 2011 14:25:11 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:dbe1e07e-b02e-4aa9-a5eb-c895706b53ad</guid><dc:creator>Robert Trabue</dc:creator><description>&lt;p&gt;&lt;p&gt;
I believe you all are right. Thank you for your quick responses. I
am leaning toward the stack overflow idea.&lt;/p&gt;

&lt;p&gt;
A particular branch of my code under a certain operation from
Task1 that handles those large packets also saves them to a storage
media. I commented out just the part that was saving them, and the
data transfer itself causes no crash. The call to save the data
resembles this:&lt;/p&gt;

&lt;p&gt;
Mem_Write( &amp;amp;rx_pkt[ 9 ], storage_address, data_size );&lt;/p&gt;

&lt;p&gt;
Where rx_pkt is the data, data_size is extracted from the packet,
which contains the length of the data, and the algorithm sequentially
saves the data along the storage media. The data_size is always 11
less than the size of the packet, as I control the format on both
ends. It SHOULD be consistent, as a failed checksum on receipt means
that the packet is just ignored.&lt;/p&gt;

&lt;p&gt;
So, something is overflowing there in the function call, I
think.&lt;/p&gt;

&lt;p&gt;
It goes BOOM on the very first packet received if I comment out
the array, but only after it sends a response back to the data
sender. The overflow may actually be there because the response is
placed on the stack too.&lt;/p&gt;

&lt;p&gt;
That gives me a few places to start tracing. Thanks guys.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: App crashes without unused array declaration</title><link>https://community.arm.com/thread/90817?ContentTypeID=1</link><pubDate>Wed, 26 Jan 2011 14:10:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e1fb7092-dc7b-4de2-8902-0d465b3fb9da</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
... as the others have already said.&lt;/p&gt;

&lt;p&gt;
Another possible way to catch such a problem is to set a
data-write breakpoint in the supposedly &amp;quot;unused&amp;quot; array...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: App crashes without unused array declaration</title><link>https://community.arm.com/thread/59107?ContentTypeID=1</link><pubDate>Wed, 26 Jan 2011 14:04:01 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b76d81f9-a955-4182-81f3-bccee9b377e6</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Task1 cannot handle large packets without that array
declaration being present.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
That nearly certainly means that your &amp;quot;Task1&amp;quot; contains a massive
buffer overflow that currently just so happens to overflow into that
supposedly &amp;quot;unused&amp;quot; buffer. Take away the buffer, and you overflow
into some other variables --- ka-BOOM.&lt;/p&gt;

&lt;p&gt;
To test if this is your root cause, write a recognizable pattern
you wouldn&amp;#39;t have in any of your data (customary choices include
repetetions of 0xDEADBEEF), execute a test sequence that&amp;#39;s known to
trigger the crash if the buffer is absent, then inspect the buffer.
Is your tell-tale pattern still intact? Or does it, by any chance,
hold content of that big data package (or derived from that)?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: App crashes without unused array declaration</title><link>https://community.arm.com/thread/66227?ContentTypeID=1</link><pubDate>Wed, 26 Jan 2011 14:01:49 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8cf0a2dd-c037-493e-85fe-81620e2688aa</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Time to check your map file. Either you have a buffer overflow
somewhere that needs part of this memory. Try to fill the memory with
a known value and later check if it has been touched.&lt;/p&gt;

&lt;p&gt;
Another alternative is that you have a buffer overflow or absolute
address in use somewhere that overwrites something completely
different, and the existence of this unused buffer affects what
variable that is located where the buffer overrun happens.&lt;/p&gt;

&lt;p&gt;
A third alternative is that you have a stack overflow, and that
your buffer is located so that the existence/removal of the buffer
changes what will be overwritten by the stack overflow.&lt;/p&gt;

&lt;p&gt;
Buffer overruns can be evilishly hard to catch, which is a reason
for always code defensively from day one. If you play with macros,
you may even have to run the source code through the preprocessor
just to be able to spot a source code line that may somehow change a
pointer or index or in some other way result in memory addresses
where none are allowed.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>