Page 7 of 20
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Mon Mar 19, 2018 12:47 pm
by notaz
If your build process keeps the elf file you can do "addr2line -e yourgame.elf 42c0" to find the line of code, or you can look up the address in the map file. Not sure if SGDK produces those, I use custom makefiles for my stuff.
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Mon Mar 19, 2018 3:30 pm
by Miquel
It can also be a jump (pointer function for example) to an erroneous direction, and then just executing random instructions until one crashes. MAYBE.
Or a variable that gets overwritten by mistake, buffer overrun or whatever.
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Mon Mar 19, 2018 4:13 pm
by Miquel
Digging a bit deeper:
instruction: 0x3238
in binary by fields: 00 11 001-000 111-000
move.w (xxx).w, d0.w
where:
- "(xxx).w" it's the source, a memory absolute
- d0.w is the destination
So the instruction that crashes is a constant address like:
*((u16*)1) = 0;
CONCLUSION: Not a variable overwrite, not a regular pointer. Perhaps a function pointer, or perhaps a basic misalignment.
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Mon Mar 19, 2018 7:31 pm
by mix256
Ey, thanks a lot! Although it was 3228, not 3238.
So, it's in SPR_update(), then?
Last screenshot:
Code: Select all
41ba: 51c9 ffe4 dbf %d1,41a0 <SPR_update+0x256>
41be: 0242 ff0c andiw #-244,%d2
41c2: 6000 fece braw 4092 <SPR_update+0x148>
41c6: 206a 000c moveal %a2@(12),%a0
41ca: 3228 0012 movew %a0@(18),%d1
41ce: 6600 029c bnew 446c <SPR_update+0x522>
41d2: 426a 0016 clrw %a2@(22)
First screenshot:
Code: Select all
4170: 0802 0000 btst #0,%d2
4174: 6700 ff18 beqw 408e <SPR_update+0x144>
4178: 206a 000c moveal %a2@(12),%a0
417c: 326a 001e moveaw %a2@(30),%a1
4180: 3610 movew %a0@,%d3
4182: 2868 0002 moveal %a0@(2),%a4
I've done some (a lot, actually), so the addresses have changed a bit.
Don't think it's sgdk that's making this happen, though. It's probably my handling (fail handling and releasing) of sprites after getting the handle.
Although the first of these screenshots were when just leaving it at the start. And nothing sprite-wise was going on except for the main sprite being on screen with the idle animation.
Well, at least I know in what area to concentrate on now.
Thanks for the help guys!
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 12:13 am
by Miquel
mix256 wrote: Mon Mar 19, 2018 7:31 pm
Ey, thanks a lot! Although it was 3228, not 3238.
0x3228: 00 11 001-000 101-000 -> move.w (displacement, A0), D1
0x3610: 00 11 011-000 010-000 -> move.w (A0), D3
Both crash instructions seem to do similar things and the stack is at the same deep level. Seems to be that whatever is A0 (¿a pointer to a struct?) is completely wrong but only crashes when by chance is even. That's my guess
Edit: checking the asm code just you previously released you need to know from where A2 comes.
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 8:44 am
by mix256
Miquel wrote: Tue Mar 20, 2018 12:13 am
Edit: checking the asm code just you previously released you need to know from where A2 comes.
Most likely, I've got a hunch that it's trying to get the frame->time of a sprite.
But since that could have been triggered from anywhere in my sprite handling code (like, any of the SPR_setAnim() calls) tracking down the actual issue will take some work.
Edit:
This is it, I am now certain.
Code: Select all
static u16 updateFrame(Sprite *sprite)
{
#ifdef SPR_PROFIL
s32 prof = getSubTick();
#endif // SPR_PROFIL
#ifdef SPR_DEBUG
KLog_U1(" updateFrame: sprite #", getSpriteIndex(sprite));
#endif // SPR_DEBUG
// init timer for this frame (+1 as we update animation before sending to VDP)
if ((sprite->timer = sprite->frame->timer))
sprite->timer++;
The sprite->frame pointer seems to be invalid.
And I'm guessing the problem is with my HUD code.
Good day, today. Sunny outside and progress on the bugs.
If only the artist I've commissioned to do the cover gets in contact with me soon, the day would be perfect.
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 1:59 pm
by Miquel
Is that code yours or belongs to SGDK?
Then what is wrong is "Sprite *sprite", the stack parameter... which gets overwritten somehow... estrange that the stack gets mess up...
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 2:15 pm
by mix256
Miquel wrote: Tue Mar 20, 2018 1:59 pm
Is that code yours or belongs to SGDK?
Then what is wrong is "Sprite *sprite", the stack parameter... which gets overwritten somehow... estrange that the stack gets mess up...
It's SGDK, and I don't think there's something wrong with the stack. It's the spirte->frame that is messed up. Because of an animation frame not being properly set, somehow/somewhere. Most likely in my HUD code.
In fact, there is no stack involved when calling the updateFrame(), it just seem to branch over there:
Code: Select all
40ec: 0800 0006 btst #6,%d0
40f0: 6600 01f8 bnew 42ea <SPR_update+0x27c>
...
...
42ea: 206a 000c moveal %a2@(12),%a0
42ee: 3228 0012 movew %a0@(18),%d1
42f2: 6600 029c bnew 4590 <SPR_update+0x522>
That btst #6 is coming from SPR_update():
Code: Select all
if (status & NEED_FRAME_UPDATE)
status |= updateFrame(sprite);
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 2:40 pm
by Miquel
mix256 wrote: Tue Mar 20, 2018 8:44 am
Code: Select all
static u16 updateFrame(Sprite *sprite)
Unless it's inlined by the compiler, all parameters are stored on the stack by gcc. No way around. a7 is the stack pointer but could get copied to another address/pointer register. There is no "bnew" instruction, perhaps is a psedo-code for gcc itself?
But if you are sure that the problem resides on "spirte->frame" it really doesn't matter.
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 2:49 pm
by mix256
You're pulling my leg, of course BNE exists and for word.
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 3:30 pm
by Stef
There was a bug in the previous SGDK version where timer wasn't correctly reset, so you can end with incorrect animation timing but as far i know i never meet issue with the frame pointer itself. Are you sometime calling setFrame by yourself ?
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 4:12 pm
by mix256
Stef wrote: Tue Mar 20, 2018 3:30 pm
There was a bug in the previous SGDK version where timer wasn't correctly reset, so you can end with incorrect animation timing but as far i know i never meet issue with the frame pointer itself. Are you sometime calling setFrame by yourself ?
No, I don't but doing a SPR_setAnim() with an invlid anim could render this issue, right? I guess, this could create an invalid frame pointer in SPR_setAnim() ?
Code: Select all
sprite->frame = animation->frames[frameInd];
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 4:37 pm
by Miquel
mix256 wrote: Tue Mar 20, 2018 2:49 pm
You're pulling my leg, of course BNE exists and for word.
Yes, "bne" exists! and perhaps new versions of gcc are passing arguments throw d0/d1/a0/a1. My bad.
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 5:12 pm
by Sik
Note that most compilers will not bother with a call to subroutine when the function would immediately return once the subroutine is done, they'll just jump straight to it since the result will be the same (this is a common optimization when programming in asm, too).
Re: Unnamed "ninja" game (Dev Diary thread)
Posted: Tue Mar 20, 2018 5:19 pm
by Stef
mix256 wrote: Tue Mar 20, 2018 4:12 pm
Stef wrote: Tue Mar 20, 2018 3:30 pm
There was a bug in the previous SGDK version where timer wasn't correctly reset, so you can end with incorrect animation timing but as far i know i never meet issue with the frame pointer itself. Are you sometime calling setFrame by yourself ?
No, I don't but doing a SPR_setAnim() with an invlid anim could render this issue, right? I guess, this could create an invalid frame pointer in SPR_setAnim() ?
Code: Select all
sprite->frame = animation->frames[frameInd];
For sure it could lead to incorrect frame pointer if you use setAnim (or setFrameAndAnim / setFrame) with incorrect index :p i'm not doing any bounds verification (for performance reason obviously).