buserror / simavr

simavr is a lean, mean and hackable AVR simulator for linux & OSX
GNU General Public License v3.0
1.56k stars 365 forks source link

Adding elements to struct avr_t reveals memory corruption issues... #17

Closed bsekisser closed 10 years ago

bsekisser commented 11 years ago

Debian 6; gcc 4.4.5 (Debian 4.4.5-8) Debian 7; gcc 4.7.2 (Debian 4.7.2-5) << still setting up though the issues still seem to exist.

Have several bug fixes I'll be putting pull requests (assuming I can figure it out...;)for issues I have found so far (one definite(elf symbols), one potential(loading code)) and another I'll should be pushing asap (irq observed memory block movement errors)... I see recent commits (which I still need to pull) and am still observing telltale signs of memory corruption issues even with the fixes I have made to my code base... Therefore it was time to put up an issue in case others find themselves faced with unknown oddities.

buserror commented 10 years ago

Is this still active?

bsekisser commented 10 years ago

Don't know... Stopped trying early on and found another way to do what I needed... using globals and then later piggybacked on existing data.

I'll try putting in some junk in the avr_t structure at various places and see what happends.

On Tue, 04 Mar 2014 00:48:58 -0800 Michel Pollet notifications@github.com wrote:

Is this still active?


Reply to this email directly or view it on GitHub: https://github.com/buserror-uk/simavr/issues/17#issuecomment-36603251

bsekisser commented 10 years ago

At the moment looks like the problem may no longer exist... littered the struct with junk and no crashes.

I do know some changes came along which did address the possibility of memory corruption issues. So hopefully one of them did the fix.

On Tue, 04 Mar 2014 00:48:58 -0800 Michel Pollet notifications@github.com wrote:

Is this still active?


Reply to this email directly or view it on GitHub: https://github.com/buserror-uk/simavr/issues/17#issuecomment-36603251

buserror commented 10 years ago

I think I know what was going on, it was due to something related to the atmega8. I'll have to document the behaviour at some point. The key thing is that you /can't/ have a #ifdef in a core definition...