Memory-overwrites

Nick Mueller · 2007-04-11 22:19

Hi!

I know that this is a *very* unprecise question and that your answers will be even more vague. But I'll give it a try:

Writing an application, I see from time to time that I'm getting memory overwrites. I'm using the TV-object and when I do get an overwrite, I get fancy patterns in one of the screen's corners. Well, moving things around, I sometimes happen to fix them. Ain't the right way, I know!
The worst case I have now is with including the OBJ "keyboard". Just by the sole OBJ-statement (without any initialisation) my app doesn't start.

Now where do I have to look at?
The stack? But I only have one cock running my app and another one running some ASM I wrote.
I tried to write padding arrays of longs to see who might be the cause, but didn't help.

TIA,
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Mike Green · 2007-04-11 22:26

Actually, there's a fairly precise answer ... Post your program

The causes of this kind of behavior are legion. The best way to find the problem is to carefully go through the code checking that your assumptions about addresses, subscripts, stack sizes, etc. are actually followed rather than just assumed. Strange or odd problems can be due to stack overflow, but usually are not.

Nick Mueller · 2007-04-11 23:18

> Actually, there's a fairly precise answer ... Post your program

<G> I didn't want to hear that answer.

What I'd like to know is, that are pitfalls specific to SPIN. I'm (or was) familiar with many languages (and their pitfalls). So I do already pay attention to indices.

If I still don't get an answer I like, I'll try to boil it down and post the code.

Thanks,
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Paul Baker · 2007-04-11 23:27

Unlike C and other languages heavily reliant upon pointers, Spin/PASM code (memory-wise)·is typically well behaved by it's nature. The only way you are going to end up with overwrites are if you overrun your spin stack (simple enough to expand, but if the corruption is occuring at a random place, its not the stack since it will encroach from a specific direction), or you are using pointers. Check all instances of wrlong/wrword/wrbyte in your asm code and be sure you are using them correctly (remember the source and destination are reversed), also check your pointer math to make sure your not misusing it in either Spin or assembly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 4/11/2007 11:32:33 PM GMT

Nick Mueller · 2007-04-13 12:33

OK, can't get it working.
I bet it is my error, but really don't have even the slightest clue where it is.
This example is quite boiled down, so you don't have to wade through lots of code. I have put comments where the problems appear (two traps)

{
  I do have two problems with this code:

  1.) If I just include the OBJ "keyboard", I get no display at all
  2.) If I uncomment the VAR "filler", I get some overwrites to the screen and no display of the text
  
}
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5000000
  
  x_tiles = 16
  y_tiles = 12

  paramcount = 14       
  bitmap_base = $2000
  display_base = $5000

  lines = 5
  thickness = 2
  
OBJ
  Scrn  : "tv"
  gr    : "graphics"
  floats : "FloatMath"
  floatstring : "FloatString"
  
' **** as soon as the next line is un-commented, the screen stays black
'  kb      : "keyboard"

VAR
  long  tv_status     '0/1/2 = off/visible/invisible           read-only
  long  tv_enable     '0/? = off/on                            write-only
  long  tv_pins       '%ppmmm = pins                           write-only
  long  tv_mode       '%ccinp = chroma,interlace,ntsc/pal,swap write-only
  long  tv_screen     'pointer to screen (words)               write-only
  long  tv_colors     'pointer to colors (longs)               write-only               
  long  tv_hc         'horizontal cells                        write-only
  long  tv_vc         'vertical cells                          write-only
  long  tv_hx         'horizontal cell expansion               write-only
  long  tv_vx         'vertical cell expansion                 write-only
  long  tv_ho         'horizontal offset                       write-only
  long  tv_vo         'vertical offset                         write-only
  long  tv_broadcast  'broadcast frequency (Hz)                write-only
  long  tv_auralcog   'aural fm cog                            write-only

' **** uncommenting the next line makes some fancy pattern on the screen
'  long  filler[noparse][[/noparse]400]

  word  screen[noparse][[/noparse]x_tiles * y_tiles]
  long  colors[noparse][[/noparse]64]
  
  long flt
  
PUB Main | Temp, i, dx, dy

  longmove(@tv_status, @tvparams, paramcount)
  tv_screen := @screen
  tv_colors := @colors

  'init colors
  'code was just copied from Graphics_Demo
  repeat i from 0 to 63
    colors[noparse][[/noparse] i ] := $00001010 * (i+4) & $F + $2B060C02

  'init tile screen
  'code was just copied from Graphics_Demo
  ' **** Seems I can make some fancy color-fading with that. Don't need that, but doesn't matter
  repeat dx from 0 to tv_hc - 1
    repeat dy from 0 to tv_vc - 1
      screen[noparse][[/noparse]dy * tv_hc + dx]:= display_base >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10)
  
  Scrn.start(@tv_status)

  'start and setup graphics
  gr.start
  gr.setup(16, 12, 128, 96, bitmap_base)
  gr.textmode(4, 4, 6, %1010)

  FloatString.SetPrecision(5)

  repeat
    gr.clear
    gr.colorwidth(2, 3)

    gr.text(-80, 110, string("X:"))
  
    Temp:= 123

    flt:= Floats.ffloat(Temp)
    flt:= Floats.fmul(flt, 0.00124)

    gr.finish
    gr.colorwidth(2, 3)
    gr.text(120, 108, FloatString.FloatToString(flt))

    gr.copy(display_base)

DAT

tvparams                long    0               'status
                        long    1               'enable
                        long    %001_0101       'pins
                        long    %0000           'mode
                        long    0               'screen
                        long    0               'colors
                        long    x_tiles         'hc
                        long    y_tiles         'vc
                        long    10              'hx
                        long    1               'vx
                        long    0               'ho
                        long    0               'vo
                        long    0               'broadcast
                        long    0               'auralcog

Hope that someone of the (more than me) enlightened ones can help me.

TIA!
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Post Edited (Nick Mueller) : 4/13/2007 1:50:40 PM GMT

Kaio · 2007-04-13 13:29

Nick,

I have found one error on init colors. You have lost the index on left side of this expression.

  repeat i from 0 to 63
    colors[i] := $00001010 * (i+4) & $F + $2B060C02
[/i]

Nick Mueller · 2007-04-13 13:47

> I have found one error on init colors. You have lost the index on left side of this expression.

That was discarded by the HTML-formatter (or whoever). The "[noparse][[/noparse] i ]" was interpreted as format-in-italic. Putting blanks around the i fixed that.
It is in the code.
I have fixed the posting of the code to display the brackets.

Thanks,
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Post Edited (Nick Mueller) : 4/13/2007 1:58:07 PM GMT

Mike Green · 2007-04-13 15:02

You may be running out of memory. The graphics demo was written to use fixed areas in memory for the screen buffer and an additional display bitmap which occupy all memory above $2000 (bitmap_base = $2000 ... occupies $2000 to $4FFF and display_base = $5000 ... occupies $5000 to $7FFF). That doesn't leave much. There are some provisions in Spin to have the compiler check for available memory (_stack = ... or _free = ...), but this program didn't use them. The graphics driver normally uses double buffering which makes the display look nicer, but doubles the amount of graphics memory needed. Some people have switched to single buffering which frees up a bit of memory. Other options are to use a smaller graphics bitmap (smaller screen area for graphics) and use just plain text on the rest of the screen.

Paul Baker · 2007-04-13 16:25

Nick if you hit F8 while you have your top object displayed it will show you how many longs you have in your stack/free area.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Nick Mueller · 2007-04-13 17:00

> Nick if you hit F8 while you have your top object displayed it will show you how many longs you have in your stack/free area.

Thanks, I'm aware of that and did check (albeit, I didn't post it). I do have more than 6000 stack/free.
That should be enough?
Even if I include a "_STACK = 200"*) and compile, it hangs when just including/importing the keyboard.spin-OBJ.

Could someone actually compile my code and say what I did wrong? I know that I sound dumb, but I also know, that I'm programming since decades.

*)
That's something really puzzling me. Reading in the printed manual at page 107 it says that it will explain more, but I can't find more about it. I'm aware that there is some Stack-checker available (filling with A5-pattern). OTOH, I can't see why 6000 longs free shouldn't be enough.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Mike Green · 2007-04-13 17:20

You only have $2000 (8K) bytes available for your program and data areas because of the display and bitmap buffers used. When you include the keyboard.spin object you're probably pushing the stack into the bitmap buffer. Try including a "_free = $6000" in your program. You'll see that there's no room left.

It looks like you're not actually using the graphics except to display text. There's a text-only display driver for TV output that takes very little memory. Have a look at "tv_text.spin" and "tv_text_demo.spin". There's also a more capable windowed text display routine by Phil Pilgrim (see: http://forums.parallax.com/showthread.php?p=590631).

Nick Mueller · 2007-04-13 17:30

> You only have $2000 (8K) bytes available for your program and data areas because of the display and bitmap buffers used.

Ah! graphics just takes the memory without some kind of defining/claiming it at compile-time. I have to do that by hand. Right?

> It looks like you're not actually using the graphics except to display text.

Well, I need the characters in different sizes. And maybe some lines. I'll try the single-buffered.

Thanks
Nick (more RAM!)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Mike Green · 2007-04-13 17:35

For some reason, the bitmap and display buffer starting addresses were defined as constants (bitmap_base and display_base) and not well documented. They're not otherwise declared

Nick Mueller · 2007-04-13 17:46

> They're not otherwise declared

Now I found my error.
Taking an N-th look at Graphics_Demo, I see the _stack statement claiming the memory for the bitmap and the buffer. And -tata!- it no longer compiles.

Thanks for your helping hands!
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Paul Baker · 2007-04-13 18:04

Thanks Mike, I forgot the display buffer wasn't explicitly declared.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Memory-overwrites

Comments