[coldfire-gnu-discuss] Re: systemcall select() seems to overwrite variables on the stack
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[coldfire-gnu-discuss] Re: systemcall select() seems to overwrite variables on the stack
- To: coldfire-gnu-discuss@xxxxxxxxxxxxxxxx
- Subject: [coldfire-gnu-discuss] Re: systemcall select() seems to overwrite variables on the stack
- From: Tom Evans <thomasaevans@xxxxxxxxxxxxxxx>
- Date: Sat, 30 Oct 2010 00:11:54 +1100
On 10/12/10 2:33 AM, Andreas Wehrmann wrote:
> A colleague and I managed to write a test program that reproduces
> a problem related to calling select().
> ...
> ldi_dev.c before select_fd=67 | nfds = 68
> ldi_dev.c before select_fd=67 | nfds = -2141341700
Which is 0x805DB7FC. That may point to the problem.
What does that point to in your map file? You should be able to find
from the map (or with a bit of debugger help) what data structures are
there. If that doesn't help, can you set a watchpoint on that in your
debugger (or gdb) and see what accesses it? Or stop in the debugger and
dump around that address to see what it looks like.
Less likely:
http://forums.freescale.com/t5/68K-ColdFire-reg-Microprocessors/5208-SDR-SDRAM-MOVEM-L-Instruction-Whacks-Stack-otherwise-SDRAM/m-p/3152
That was caused by setting the SDRAM controller to do an 8-byte burst
where the hardware only supported 4, and this was only triggered by the
movem.l. I think I've also heard of a similar problem where the stack
pointer isn't initialised to a multiple of 4 bytes on some
architectures. Check the stack pointer value when it fails. It might be
16-bit-odd.
--
=========
Tom Evans