break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 20:28 #1

Home away from home

@All

I am in need to debug one app that didn't crash but instead stuck at some point. The usual printf way didn't help much, so I want to do as people do with GDB: they load up a binary, waiting till the necessary moment, press "ctrl+c" and then type "backtrace" and they see the current stack trace.

Now, with our GDB it can works if only our current GCC didn't produce Dwarf4 debug based binaries (as it now what all the ppls use in whole worlds), but our GDB is too old, and can only handle Dwarf2 binaries. So I need to rebuild adtools the apply the necessary patch so it will build Dwarf2 based bins. Not sure though if there also will be no needs to rebuild all link libraries too :(

So, I tried DB101: while it loads up fine, etc, etc it just didn't have the functionality to broke the process when I need and to see stack trace (at least I can't see).

Then I tried SpotLess: that one even didn't work. It runs, i can load up binary, but when I hit "start" nothing happens.

Now, question: maybe we have some debug-app, just to watch stack-trace at the time we need to give app? Maybe just some tool, which we run like "stack watch binary", and then it handles some key-combo, which when we press, just open up a window with a stack trace?

Join us to improve dopus5!
AmigaOS4 on youtube

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 20:42 #2

Just popping in

@kas1e

The problem is the ancient version of binutils in adtools. It needs some love, from someone with a lot of patience. It's a very hairy patchset for a very hairy piece of code.

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 20:46 #3

Just popping in

@kas1e

What I was trying to say was that I think it's a better idea to try to update GDB than to patch GCC

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 20:46 #4

Home away from home

@sTix
Yeah, I know :) That need to deal with the issue somehow now, not tomorrow :)

Dunno, maybe it needs to be written just some simple thing that will do exactly that: attach to the process, wait for the key combo, and then dump stack trace of a process once the combo is recieved.

I just think it is somewhere written already, just can't remember what/where.

Join us to improve dopus5!
AmigaOS4 on youtube

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 20:49 #5

Home away from home

@sTix
Quote:

What I was trying to say was that I think it's a better idea to try to update GDB than to patch GCC

Patch GCC it just that: https://github.com/sba1/adtools/pull/7 ... 8face2b0047eadfc5b1c04b01

So only (i hope) need to rebuild my gcc and it will produce dwarf2 bins and i will be able to do that in our ancient gcc. At least, that it more realistic than new GDB port which no one able to do in latest 15 years :)

Join us to improve dopus5!
AmigaOS4 on youtube

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 20:55 #6

Just popping in

@kas1e
Quote:

Yeah, I know :) That need to deal with the issue somehow now, not tomorrow :)

Dunno, maybe it needs to be written just some simple thing that will do exactly that: attach to the process, wait for the key combo, and then dump stack trace of a process once the combo is recieved.

I just think it is somewhere written already, just can't remember what/where.

I understand. I don't think we can find anyone that can / want to update binutils before midnight so I'm afraid you need to resort to something more creative

How close can you get with printfs?

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 20:59 #7

Home away from home

@sTix
Quote:

How close can you get with printfs?

Nothing I can understand :) I then just ask the authors about it, and they say that they need stack trace on the moment the game stuck. So, fighting with that piece of shit. I hope that once I get the backtrace and send it to them, they, as authors, will help out to fix it.

Join us to improve dopus5!
AmigaOS4 on youtube

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 21:04 #8

Just popping in

@kas1e
Quote:

Patch GCC it just that: https://github.com/sba1/adtools/pull/7 ... 8face2b0047eadfc5b1c04b01

So only (i hope) need to rebuild my gcc and it will produce dwarf2 bins and i will be able to do that in our ancient gcc. At least, that it more realistic than new GDB port which no one able to do in latest 15 years :)

Ah, it's that simple. Sounds like a stop gap solution if it works.

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 21:15 #9

Just popping in

@kas1e
Quote:

Nothing I can understand :) I then just ask the authors about it, and they say that they need stack trace on the moment the game stuck. So, fighting with that piece of shit. I hope that once I get the backtrace and send it to them, they, as authors, will help out to fix it.

Ah, yes if the authors are willing to take a look I can understand that they want more than just printf output.

I'm working on your namespace problems BTW. It was a bit more work than I antecipated, lots of things missing in clib2.

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 21:18 #10

Home away from home

@sTix
Quote:

I'm working on your namespace problems BTW. It was a bit more work than I antecipated, lots of things missing in clib2.

clib2 is loooong road. If things at least will works with newlib at the start that will be good too.

Join us to improve dopus5!
AmigaOS4 on youtube

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 21:33 #11

Just popping in

@kas1e
Quote:

clib2 is loooong road. If things at least will works with newlib at the start that will be good too.

Yep, the road is long, but it's not blocked by concrete slabs and dragons (and there's food along the way).

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/30 21:57 #12

Just can't stay away

@kas1e

To get a stack trace from a specific point in a program you can just insert in the source code a:

IExec->SuspendTask(NULL, STF_CRASHED)

there and it should bring up the grim reaper.

Or you could just do something like:

*(char *)0 = 0;

which will trigger a DSI and bring up the grim reaper as well.

Using Ranger you can also get a stack trace from any running program by selecting it from the process list and clicking the button next to "Stack:".

LiveForIt

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 0:54 #13

Home away from home

@kas1e

A program can’t stack trace itself,
you need start a process that can do it,
next you need suspend main program process,
run stack trace on main program process,
unsuspend main program, and exit debug process.
continue program.
something like that anyway.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 5:19 #14

Home away from home

@salas00
Quote:

To get a stack trace from a specific point in a program you can just insert in the source code a:

IExec->SuspendTask(NULL, STF_CRASHED)

there and it should bring up the grim reaper.

Or you could just do something like:

*(char *)0 = 0;

A problem that I didn't know where I stuck in the code (because of too much for's loops, ifs, and elses) So I want to grab stack trace when I see issue visually without knowing where the issue in code is.

Quote:

Using Ranger you can also get a stack trace from any running program by selecting it from the process list and clicking the button next to "Stack:".

Yeah, thanks! While it didn't resolve symbols in the app itself, I still can get addresses and via addr2line got the necessary ones.

Through, what is interesting, when I run the game and go to the menu, and click on that "stack" button, it shows me many addresses as expected in the stack trace (and kernel, and graphics libs, and many addresses from my binary). Then once I run it and game stuck on loading md5 mesh, then in the stack trace of ranger all I have is 2 lines:

0x7ee4fe88 0x1EDE70 game
9x91a628e9 0x87e8 newlib.library.kmod

Where all the functions went which call that one ?:)

Anyway, seems that this is for real the function where i stuck! And it looks like this:


template<int BPP> static void shifttexture(uchar * RESTRICT src, uint sw, uint sh, uint stride, uchar * RESTRICT dst, uint dw, uint dh)

{

    

    

    uint wfrac = sw/dw, hfrac = sh/dh, wshift = 0, hshift = 0;



    while(dw<<wshift < sw) {

        wshift++;

    }

And this "while" never ends.

Edited by kas1e on 2021/1/31 6:40:58
Edited by kas1e on 2021/1/31 6:54:01
Edited by kas1e on 2021/1/31 6:54:34

Join us to improve dopus5!
AmigaOS4 on youtube

flash

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 7:38 #15

Just popping in

Use simple printf and assure to avoid division by zero and all other values are as expected.

Anyway it could be an endian issue ..are you sure << operator have to shift values on left and not instead on right for big endian platforms?

Memento audere semper!

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 7:48 #16

Just can't stay away

@kas1e

IIRC result of shift operation is undefined when wshift >= (sizeof(dw)*8).

Try changing the loop to:

while (wshift < (sizeof(dw)*8) && (dw << wshift) < sw) {
wshift++;
}

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 8:05 #17

Home away from home

@Salas00

Tried like this:


template<int BPP> static void shifttexture(uchar * RESTRICT src, uint sw, uint sh, uint stride, uchar * RESTRICT dst, uint dw, uint dh)

{

    uint wfrac = sw/dw, hfrac = sh/dh, wshift = 0, hshift = 0;

    //while(dw<<wshift < sw) wshift++;

    

    while (wshift < (sizeof(dw)*8) && (dw << wshift) < sw) {

        wshift++;

    }



    while(dh<<hshift < sh) hshift++;



    uint tshift = wshift + hshift;

    for(uchar *yend = &src[sh*stride]; src < yend;)

    {

        for(uchar *xend = &src[sw*BPP], *xsrc = src; xsrc < xend; xsrc += wfrac*BPP, dst += BPP)

        {

            uint t[BPP] = {0};

            for(uchar *ycur = xsrc, *xend = &ycur[wfrac*BPP], *yend = &src[hfrac*stride];

                ycur < yend;

                ycur += stride, xend += stride)

            {

                for(uchar *xcur = ycur; xcur < xend; xcur += BPP)

                    loopi(BPP) t[i] += xcur[i];

            }

            loopi(BPP) dst[i] = t[i] >> tshift;

        }

        src += hfrac*stride;

    }

}

Same stuck, and ranger show address which is that "wshift++;" in the while.

Join us to improve dopus5!
AmigaOS4 on youtube

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 8:11 #18

Just can't stay away

@kas1e

Probably the same problem with the next loop.

Addr2line is not that accurate so it can be off by a few lines/statements.

Re: break an app at need it time to see current stack trace of it.

Posted on: 2021/1/31 8:20 #19

Home away from home

@salas00

Yeah, tried like this:


template<int BPP> static void shifttexture(uchar * RESTRICT src, uint sw, uint sh, uint stride, uchar * RESTRICT dst, uint dw, uint dh)

{

    uint wfrac = sw/dw, hfrac = sh/dh, wshift = 0, hshift = 0;



    //while(dw<<wshift < sw) wshift++;

    while (wshift < (sizeof(dw)*8) && (dw << wshift) < sw) {

        wshift++;

    }



    //while(dh<<hshift < sh) hshift++;

    while (hshift < (sizeof(dh)*8) && (dh << hshift) < sh) {

        hshift++;

    }



    uint tshift = wshift + hshift;

    for(uchar *yend = &src[sh*stride]; src < yend;)

    {

        for(uchar *xend = &src[sw*BPP], *xsrc = src; xsrc < xend; xsrc += wfrac*BPP, dst += BPP)

        {

            uint t[BPP] = {0};

            for(uchar *ycur = xsrc, *xend = &ycur[wfrac*BPP], *yend = &src[hfrac*stride];

                ycur < yend;

                ycur += stride, xend += stride)

            {

                for(uchar *xcur = ycur; xcur < xend; xcur += BPP)

                    loopi(BPP) t[i] += xcur[i];

            }

            loopi(BPP) dst[i] = t[i] >> tshift;

        }

        src += hfrac*stride;

    }

}

And this time not stuck, but crash instead on "loopi(BPP) dst[i] = t[i] >> tshift;"

Join us to improve dopus5!
AmigaOS4 on youtube