Bus Error - Reasons?

[mrdalliard]

Hi,

Here's the next installment of "noob attempts to code ASM" in the series.

I've been writing a program which is giving two bombs (bus error) right at the end. In MON, it looks like it's an RTS instruction that's causing the error.

Does that mean that I've left something on the stack? My pushes don't balance with my pops? My hunch is that I've not that I've not got the size right on an "add.l <x>, sp" line somewhere, but I'm probably wrong.

Any direction to find the cause gratefully received.

Thanks,

M.

[Cyprian]

Hi,

Here's the next installment of "noob attempts to code ASM" in the series.

I've been writing a program which is giving two bombs (bus error) right at the end. In MON, it looks like it's an RTS instruction that's causing the error.

does this mean you have RTS at the end of your code?
Correct exit from the APP is e.g "Pterm0".

Code: Select all

move.w    #0,-(sp)     ; Offset 0
trap      #1           ; GEMDOS
addq.l    #2,sp        ; Correct stack <-- that is never reached

[chronicthehedgehog]

Interesting. I've got a similar problem at the moment. However, using libcmini's exit function (which calls Pterm(n)), but only in TOS 3.06 (using Hatari)

EDIT:

When I say 'only', TOS 2.06 works fine. Not tried anything else

[chronicthehedgehog]

In my case it was just a dodgy TOS image. Found another 3.06 and works fine.

Sorry for threadjacking, but it seemed like the same problem

[mrdalliard]

Hi,

Here's the next installment of "noob attempts to code ASM" in the series.

I've been writing a program which is giving two bombs (bus error) right at the end. In MON, it looks like it's an RTS instruction that's causing the error.

does this mean you have RTS at the end of your code?
Correct exit from the APP is e.g "Pterm0".

Code: Select all

move.w    #0,-(sp)     ; Offset 0
trap      #1           ; GEMDOS
addq.l    #2,sp        ; Correct stack <-- that is never reached

No, I'm using subroutines in an include - the RTS concerned is from a subroutine that's in there.

I'm using pterm at the end of my code, but it doesn't quite reach that.

Cheers,

M.

[mrdalliard]

Well, I've found the nature of the error (through eliminating chunks of code) although I'm not sure how to correct it.

I raised this on a previous thread, about trying to call other programs and the suggestion was to free up excess memory before calling other programs. I've obviously got this wrong somehow, using the code at - https://freemint.github.io/tos.hyp/en/gemdos_tpa.html

Not sure whether I've not allocated enough.... the page says 8000 bytes, but I'm assuming that bigger programs need more?

Thanks,

M.

[thomas3]

It depends on stack usage. rts will fail when the stack size isn't large enough, or there is a buffer overflow in your code, either way meaning that the stack is overwritten with garbage (because rts pulls a return address from the stack, so ends up jumping to either an illegal or arbitrary address). So there's a couple of things that could be happening here.

Definitely try a larger stack - if you're calling compiled STOS, it has some insane nested stack usage (with heaps of register backups to stack too). Is there any chance your code is doing something naughty and writing outside of declared memory areas/banks?

[thomas3]

Also. Do any of your subroutine calls work? This could be a relocation issue if not.

[mrdalliard]

Also. Do any of your subroutine calls work? This could be a relocation issue if not.

Yes, the others work fine right up to the last point.

So, I'm using that nice 68K tutorial that's on another thread https://nguillaumin.github.io/perihelio ... index.html. The bus error comes up just as I'm restoring everything, ready to quit. (The issue comes up in the "restore" subroutine that is mentioned lots of times in the tutorial, just as you're restoring the resolution, palette, etc... just before the program terminates)

This does suggest you're right and I've not allocated enough memory. I'm including a degas pic in the program, so perhaps I should be adding at least another 32K.

Thanks,

M.