amigaos4 port

[kas1e]

Howdy ! Its me :)

So, to make amigaos4 version possible need to add those changes:

1. src/backtrace.c

replace all #ifndef _WIN32 (in 1 place) and #ifndef WIN32 (in 5 places) , on #if !defined(_WIN32) && !defined(__amigaos4__)

2. src/main.h

at top change as for Pandora to use float instead of double:

#ifdef __amigaos4__
 #undef Double
 #define Double float
#endif

and get rid of "#error KO":

#ifdef NEON
 #include <arm_neon.h>
#else
#ifndef __amigaos4__
 #error KO
#endif
#endif

3. src/time_util.h

line 72 : #if 1 change on #if 0 for amigaos4 line 103: #if 1 change on #if 0 for amigaos4

4. src/term.c

replace all #ifndef _WIN32 on #if !defined(_WIN32) && !defined(__amigaos4__)

5. src/main.c

at moment comment out execve():

#ifndef __amigaos4__
#ifdef _WIN32
    execve(executable, (const char *const *) args, 0);
#else
    execve(executable, (char *const *) args, 0);
#endif
#endif

And that all. + changes in makefiles , but that can go for latter (i can create just makefile.os4 and makefile_os4.ramdisk).

Now, when i run game, i have as usuall for big-endian inverted colors. As well, as menu didn't draws (or just can't be seen) and character at left also can't be seen.

There is screenshot of menu:

http://kas1e.mikendezign.com/aos4/gl4es/games/gorynlich/gorynlich_1.jpg

Then, i check how it all loads, and find out that its load_image() from tex.c. And that one for sure have ENDIAN checks. So, for sake of tests, i comment out big-endian ifdefs in that functinos, and wtf , colors start to be right ! Check this out:

http://kas1e.mikendezign.com/aos4/gl4es/games/gorynlich/gorynlich_2.jpg

Through, menu not visibly still, and no character visibly at left bottom of screen.

And strange, why removing of endian ifdefs make colors be better , but not in other way :)

[goblinhack]

Oh yeah, and none of my stuff uses shaders - I never quite got around to understanding them 8) also for performance, the lighting is usually the culprit - maybe #define MAX_LIGHT_RAYS 360 could be tweaked a bit lower. I seem to recall ENABLE_LARGE_TEXT_OUTLINE was expensive too... As for memory, I can't recall the main culprits.

[kas1e]

Howdy :) The main problem there is that its need a lot of memory just to start a level : from 500mb to 1.2 gb just for one level. That currently is only one stop-factor from release for amigaos4 (for Pandora ptitseb use SwapFile for), but i just can't release a port for amigaos4 , where the 2d game want ~1gb of memory , they will cry at me and says that old games take just 1-2 mb, and taking 1gb for just a level generation is too much. And you can't explain them anything about how progressive is it, and how hard levels is , they will keep repeat the same :)

So there we need somehow to reduce maximum memory usage. At least to 300-400mb for any level, that can fit in amigaos4 easy.

[ptitSeb]

I had something in progress to reduce memory footprint (using c++ would also help there, by using std::vector instead of fixed sized array), but it's buggy for now. Hopefully, I'll find that bug soon.

Thanks for the hint for MAX_LIGHT_RAYS, I'll try to experiment later, see if I can fine tune all that.

And I'll give zorbash a try later.

[goblinhack]

you could try lowering MAP_THINGS_PER_CELL - the risk is that if a lot of explostions happened in the same location it might run out of thing slots at that location. And changing this to a std::vector

typedef struct { uint8_t count; uint32_t id[MAP_THINGS_PER_CELL]; } thing_map_cell;

might help - or to a list, or something that isn't 4*128 bytes per map cell!

another hacky idea might be to change double to float in thing.h to save space

JIGPIECE_MAX might also be lowerable a bit, maybe 10000

and I bet MAP_MAX could be changed to 128

you could also lower MAP_WIDTH and HEIGHT - I always felt the levels were too large anyway, as long as they are a multiple of JIGPIECE_WIDTH it should be ok - tho that would mean all of the previously saved levels would fail... I mean if you want to create new levels, then that would be one way to lower the map size and save memory

hth

[kas1e]

@ptitSeb Btw, about high-memory usage, maybe together with lowering all the things goblihack point out us, maybe it possible to use GPU's memory more somehow, so to offload system's memory usage ?

[ptitSeb]

Nope, the memory here is used to construct the level. There is nothing graphical here. I know how to reduce the memory, but for now, I'm focussed on another project, box86, were I've started writing a DynaRec and because it's quite complex, I need to stay focus on that one. Sorry, I'll go back to that later, but not right now.

[kas1e]

Aha got it , no problems of course :) Thanks !

[kas1e]

Yo ptitSeb! :) Haven't you tired with box86 ?:) Just asking, maybe you have some interest to go back to that one about reducing memory usage in gorynlich :)

[ptitSeb]

Ha ha... Nope, not tired yet of Box86 ;)

But yeah, I'll try to finish that optimization on gorynlich soon.

[ptitSeb]

@kas1e : I have finaly update the jigsaw maze generator. I think memory consumption will be much lower now!

[kas1e]

Oh, good news ! Will try now and report back, thanks! Is it enough now for you do not have a swap file on pandora? (i remember there were needs for 1gb of swap file ?)

[ptitSeb]

I don't know. I always have a 4Gb swap active... And I haven't try to unmount it.

[kas1e]

Tried to at least change only those 2 files you touch today, and when tried to do a "quick start", have in console that:

Client: Level 1.5[0x5096c008] (client): created
Client: Level 1.5[0x5096c008] (server): created
Client: Level 1.5[0x5096c008] (server): Level generating
Dying: Died at map_jigsaw.c:dieat():331
FATAL ERROR: Died at line 1982, col 0: expecting start of line
ERROR: FATAL ERROR: Died at line 1982, col 0: expecting start of line
ERROR: FATAL ERROR: Died at line 1982, col 0: expecting start of line
Client: Level 1.5[0x5096c008] (client): destroy
Client: Level 1.5[0x5096c008] (client): destroyed
exit(1) error

Strange error... But I have it even before too. Dunno if it related to memory allocation, or maybe it just some endian related issues?

[ptitSeb]

It's not all the time. It's not very often so difficult to debug on my side. You have it all the time now? How is the memory consumption?

[kas1e]

You do have that one too sometime?

Currently, I have it all the time. But probably need to rebuild everything from scratch, maybe there were some tries left of my older tests. But I am sure that error was there at the beginning.

As for memory consumption the only time I can see how much memory it wants it when starting to generate a level, and I can be wrong but it seems now want less memory for sure.

I probably need to rebuild everything from scratch firstly, just to be sure.

[kas1e]

Rebuild all the latest sources from scratch, and yeah, the issue still there when I just choose "quick start". Same when I choose "start level". Error always the same.

Through one time, when I hit "quick start", the game actually starts, and take the only 100mb for a level (strange). That was for level 1.3. Then quite from level, start another one: and this time it takes 400mb. Then again quit from level to menu and can see, that memory for sure did not feed when we come back to the menu. So when I tried to start another time, I then hit "no memory" error.

It also seems not freed memory when it exits with that "fatal error: died at line 1982".

When I reboot and tried again, than usual "fatal error: died at line 1982" back :) Weird!

And what is that "line 1982 are".. I mean which file. Because in map_jigsaw.c line 1982 seems empty?

[ptitSeb]

So, I think I have found the issue for the "died at line 1982" error (FYI, the line 1982 is from data/map/jigsaw.map :p )

Bur for the "memory leak", I don't know. I ran a valgrind test on the Pandora: start a game, ganarate a map, quit game... The "leak" was less than 100kb of memory... Nothing like the MB you mentionned. So, nothing on my side. Just a note: there is some use of realloc(...)... Is that ok on AmigaOS?

[kas1e]

Oh yes, that 1982 bug seems gone!

I.e. when I reboot and run a game, it always starts the levels and does not matter if it "quick start" or "start a game". It does not matter what level, all seems fits now.

But the issue with the memory not freed still there, and I mean not on exit from a game, but when you just exit from generated level back to the menu. I.e. you start a level, then hit "q" and exit to the menu: at this time, all the memory taken by the generation of the level not freed. And when you about to start again another level, it will have a "no memory" error, as too much was taken by the first attempt.

It, of course, can be AmigaOS issue (and probably is it), but just strange even if it realloc/calloc issues, when we exit from the level to the menu, all the generated data should be freed IMHO?

Another interesting issue I found which maybe be related to gl4es: when I run a game, start a level, exit from level, trying to start again (with non freed memory) and have "no memory", then, after that, running of the game always will have a black window (i.e. nothing renders) while whole logic works. Probably when game dies with no memory it tries to write to .gl4es.psa something which causes that effect. Once i delete .gl4es.psa all render again.

[kas1e]

About memory: the same issue happens when you for example die and want to replay a level, it then again dies with "no memory" (but then strange, because why it wants to allocate anything, as it already allocated and generated)...

[kas1e]

Found that it does not matter how I exit from the game, create .gl4es.psa on the next run always make the game be "all black color", and I need to delete .gl4es.psa.

I found also that if I just change in map_jigsaw.h 10000 on 3000 (so lower a lot), then everything seems to fits into whole 650-700mb of memory for all the time. I.e. I run game, and can as long as I wish to start/exit levels, etc. They all generated/regenerates, but memory always hit 930mb and never less and seems never more. So that ok too.

So for example, I had when system boots: 230 MB ram filled. When running binary and game start "clorping": 533 MB used. When the menu show ups: 614 Mb used. Then play a game with a quick start: 800mb used (but that sometimes more, dunno on what based) Quit to the menu: nothing changed or freed, the same 800mb used Then Quick Start: 917 Mb used. Then quit to the menu : nothing changed or freed, same 917 Mb used. Then again play a game (this time another one): 917 Mb used Quit to the menu : 917 Mb used Start a new game (another level again): 917 Mb used

In other words, in the worst case, I can just for amigaos4 release use smaller #define JIGPIECE_MAX 3000 to deal with memory allocation errors. But something still with memory on exit: when I exit from a game after that, I had 280 Mb filled, and not 230 as I have when start I game (so 50 Mb lost). Maybe something with the latest gl4es? Because as I understand, realloc issues may have an impact in the game itself, while we in, but memory shouldn't be eaten when we exit (right ?)

Also maybe if convert all .tga to something like .jpg, maybe that will reduce memory a lot as well? Has less memory be filled till the menu, also help to have more free memory when the time to generate levels?

And strangely while in the menu I have about 350 fps, in the game itself I have just about 16-25 fps. I think we also need to enable for AmigaOS4 build #define Double float too to speed things up (as currently it only enables for __ARM_NEON__ , maybe it will add some more fps as well. If I remember right, back in time when we first time test the things, you find out that with gles1 driver we had much higher FPS?

[ptitSeb]

Black screen? I don't get it. The .gl4es.psa generated at the end of the game is "corrupted"? I don't have this on the Pandora, maybe you should speak with Daniel about this issue.

Memory, I'll try something, I have seen some protential things that could save some more memory, I have to try.

tga to jpg will probably save nothing, the texture is loaded in graphic memory, so it will be uncrompressed anyway...

About the Speed, yeah, main menu is smooth, because nothing happens there. In game, I have pretty slow speed too. I haven't been able to really pinpoint something that is superslow and needs optimization. I have done a few things here and there, but nothing spectacular. If you find something that is slow, tell me.

[kas1e]

Interesting that when we actually play a game, CPU loading never reaches 100%, it always about 85% on me, not more (usually when things want to use resources, CPU busy on 100%)

[ptitSeb]

I don't what to say. I also have pretty low speed, but I don't know were is the bottleneck. If you find it, tell me, and I'll see how to remove it.

About the memory, I have done a last changed that should, again, lower memory. It seems to stay under 512MB for me now (not sure, as the swap is still there, but I haven't logged any swap in maze generation now).

[kas1e]

Tested, memory for sure lowered more! Thanks!

Btw, I found that when you exit from the game, it also leaks GPU memory. Not the usual VRAM memory (which is leaked too), but GPU only one where textures uploads. When I start the game, I have 0% of GPU memory-filled, then, when game started, it eats 152 Mb of GPU memory. Now, I didn't go to the level, just exit from the menu right away, and 6MB of GPU memory is leaked.

I, of course, need to check first on the same gl4es / ogles2 other games, if there is such leak or not, just to be sure it is gorynlich (or amigaos4 again because of realloc or something:) )

As for speed, you do have 2-3 times faster speed with gles1, that correct? (just to be sure). But that CPU loading didn't hit 100% may point out on something .. I may try to ask other devs about.

[kas1e]

So do those tests in terms of at least GPU memory leaks on exit:

Fricking shark with currently gl4es and with older gl4es which I use before (to see if there something about gl4es): and there on exit I didn't have any GPU memory leak on exit, all back to 0%.

Then tried the latest Gorynlich with older gl4es which I use before, and with last one: with both cases it enough to just run game, wait till menu, and exit from the menu, and we have 6mb of GPU memory leaked on exit. That always reproducible, and the more time you run/exit game, the more +6 leaked Mb you had.

Those tests (IMHO) show us that it's Gorynlich code leak on exit. I can think about missing SDL_ related close calls (and on Pandora garbage collector do clean things), but that probably can't explain GPU leaks? Will check.

[kas1e]

Checked sources (sdl.c ) , and there we have that kind of block:

void sdl_fini (void)
{
    if (HEADLESS) {
        return;
    }

    FINI_LOG("%s", __FUNCTION__);

    SDL_ShowCursor(0);
    SDL_ShowCursor(1);

    if (sdl_init_video) {
        sdl_init_video = 0;
        SDL_VideoQuit();
    }

#ifdef ENABLE_SDL_WINDOW /* { */
    SDL_GL_DeleteContext(context);
    SDL_DestroyWindow(window);
#endif /* } */

    SDL_Quit();
}

And it is for sure compiles and tested that we surely inside of that last ifdef, so SDL_GL_DeleteContext and SDL_DestroyWindow surely compile. Will check if they called on an exit at all (maybe whole sdl_fini() didn't called ? ). Surely it can be just forgotten free of GPU memory somewhere, just in the hope it will be something like missing call to sdl_fini :)

[ptitSeb]

I checked the code and the free are there. But maybe it was not called, because the game assume globals varibles are initialized to 0 by default (it's true on x86, but not true on ARM or AmigaOS).So I pushed some fixes, maybe it's better now?

[kas1e]

Thanks for trying, but nope :( Still the same 6mb of GPU memory-filled after exit. Does it seem that it just missing somewhere in the code maybe? I can see that in the whole when we start till menu, it takes 152mb of GPU memory, and on exit almost all freed, but 6 Mb not. So probably forgotten free of textures somewhere, will try to check, maybe can find out something

[goblinhack]

This function below should be freeing the GL memory from tex_fini called from exit.

You could also try to enable ENABLE_LEAKCHECK in main.h to see if it catches anything.

You could also try lowering MAX_LIGHT_RAYS to see if that makes it faster.

static void tex_destroy (tex *t) { SDL_FreeSurface(t->surface);

GLuint gl_surface_binding;
gl_surface_binding = t->gl_surface_binding;

if (!HEADLESS) {
    glDeleteTextures(1, &gl_surface_binding);
}

oldptr(t->surface);

}

[kas1e]

@goblinhack Thanks for suggestions! Reducing MAX_LIGHT_RAYS from 360 to 120 seems didn't change anything (not visually, not in terms of speed). I even tried 30, and nothing. So something else blocks speed. I have just about 18-25 fps maximum. I remember ptitSeb says that on glesv1 hardware it all much faster (in 2 times or something), so maybe issue amount of draw calls or some calls which is heavy for emulation by shaders?

As for memory leak, you probably mean config.h, yeah, enable it here and just run game, wait when menu showups, and quit. And nothing new printed anywhere, but GPU memory each run/quite take +6MB more.

@ptitSeb Can you check if on Pandora after exit not all GPU memory is taken by a game is freed?

[goblinhack]

Yeah it was a bit/lot slow - in my new game Zorbash I redesigned the whole display loop as it was just slow... You could try tweaking this

-#define TILES_SCREEN_WIDTH_PAD TILES_SCREEN_WIDTH -#define TILES_SCREEN_HEIGHT_PAD TILES_SCREEN_HEIGHT +#define TILES_SCREEN_WIDTH_PAD 2 +#define TILES_SCREEN_HEIGHT_PAD 2

the other thing would be to run it at a lower resolution - as the frame buffer fill for lighting was a big hit I recall.

[goblinhack]

Also you could probably just bulk replace double for float as fcos looks to be expensive

static inline double fasin (double rad) { const uint16_t index = (uint16_t)(rad / RAD_STEP); extern double FASIN[RAD_MAX];

return (FASIN[index & (RAD_MAX-1)]);

}

static inline double fcos (double rad) { const uint16_t index = (uint16_t)(rad / RAD_STEP); extern double FCOS[RAD_MAX];

return (FCOS[index & (RAD_MAX-1)]);

}

[kas1e]

@goblinkhack

Also you could probably just bulk replace double for float as fcos looks to be expensive

Yeah, ptitSeb already doing that for Pandora:

#ifdef __ARM_NEON__
 #define NEON 1
 #undef Double
 #define Double float
#endif

And i doing same for amigaos4:

#ifdef __amigaos4__
 #undef Double
 #define Double float
#endif

And then main.c had something like:

Double FSIN[RAD_MAX];
Double FASIN[RAD_MAX];
Double FCOS[RAD_MAX];

So if I understand right, ptitSeb changes that at the beginning.

I tried also to replace TILES_SCREEN_WIDTH_PAD and TILES_SCREEN_HEIGHT_PAD as you say, and that definitely improve fps! Now I even can see sometimes 35-36 fps. Which of course not superior, but at least now it more or less playable.

Maybe have any idea what else can be changed, so to reach 60 fps in end ?:)

Also, do you remember is there ability to generate the same 1:1 level (for testing purposes), because I can't see for sure that FPS changes and how much, because of levels always different, and fps always different, I can only count on the maximum fps I can see when to start 2-3 levels.

[goblinhack]

Try playing with this option to set the seed

    /*
     * -seed
     */
    if (!strcasecmp(argv[i], "--seed") ||
        !strcasecmp(argv[i], "-seed")) {

        opt_seed = atoi(argv[i + 1]);
        i++;
        continue;
    }

seed is used here

rc = generate_level(level, jigsaw_map, opt_seed);

so might work

is there a way to use any lower resolution? that would decrease the amount of pixle filling that the light algorithm does with all the draw array calls

You could also try disabling all lights except the player's - add a check in wid_light_add and if not is_player then return.

Or you could tweak this code

if (thing_is_player_or_owned_by_player(t)) {
    max_light_rays = MAX_LIGHT_RAYS;
} else {
    if (strength >= 10) {
        max_light_rays = MAX_LIGHT_RAYS;
    } else if (strength > 5) {
        max_light_rays = MAX_LIGHT_RAYS / 2;
    } else if (strength > 2) {
        max_light_rays = MAX_LIGHT_RAYS / 8;
    } else {
        max_light_rays = MAX_LIGHT_RAYS / 16;
    }
}

so that the else case is really low (non player lights) and leave the player light rays higher

lastly I seem to recall ENABLE_LARGE_TEXT_OUTLINE was slow - try disabling thst

[goblinhack]

making the map smaller would help a lot - but that would involve redesigning all the levels - so I never did that - but in hindsight 64x64 would have been more than enough!

[kas1e]

Thanks, I will try those hints as well!

Btw, is it only me on my setup, or, restarting (when changes settings from the menu) are not working? For me, I have new copy of game with new settings started, but old one is not closed. Music plays, main picture shown, just without menu.

All I do is only replace execve() in a void restart (void) of main.c, on Execute() of AmigaOS, and it actually executes with new settings, just old one didn't close/stops/etc.

is there a way to use any lower resolution? that would decrease the amount of pixel filling that the light algorithm does with all the draw array calls

From the tests I do, at least on AmigaOS4 it not very much important with Gorynlich if I use 800x600, or 1920x1080 fullscreen: fps in-game always the same.

@ptiSeb On Pandora, you can change the settings and then "restart" game from menu? It's like, destroying is never called.

[kas1e]

@goblinhack

Are you still around?

Just about to release amigaos4 port of Gorynlich, and find out that I always crash when code calling the thing_reached_teleport(), right at the beginning of a function, and it comes from the thing_collision.c . line 552 which is

thing_reached_teleport(me, it);

I.e. once I start to play at any level, once the time comes to "things_teleport" I crash there.

Have any idea maybe what to check, etc?

Thanks!

[goblinhack]

I'm guessing maybe 't" is freed after the collision check below? any more info with gdb ?

t->needs_tx_refresh_xy_and_template_id = 1;

thing_handle_collisions(wid_game_map_server_grid_container, t);

MSG_SERVER_SHOUT_AT_ALL_PLAYERS(SOUND, t->x, t->y, "teleport");

}

you could try to turn on this

undef ENABLE_PTRCHECK // Check validity of pointers too

and see if that catches anything - you could also add

void thing_reached_teleport (thingp t, thingp teleport) {

• verify(t);
• verify(teleport);

so it can then check those pointers are valid

hth

Neil

On Wed, 31 Mar 2021 at 21:02, kas1e @.***> wrote:

@goblinhack https://github.com/goblinhack

Are you still around?

Just about to release amigaos4 port of Gorynlich, and find out that I always crash when code calling the thing_reached_teleport(), right at the beginning of a function, and it comes from the thing_collision.c . line 552 which is

thing_reached_teleport(me, it);

I.e. once I start to play at any level, once the time comes to "things_teleport" I crash there.

Have any idea maybe what to check, etc?

Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ptitSeb/gorynlich/issues/1#issuecomment-811415374, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADA3H7BWGFK32WGNDWMTZLTGN5XHANCNFSM4ILEYH7A .

[kas1e]

@goblinhack

I'm guessing maybe 't" is freed after the collision check below? any more info with gdb?

If only we have working gdb :) We have some sort of dump-info when a crash happens, it just shows the register's state, stack trace, etc, and can bring some light on, but not as good as gdb of course. That how it looks like:

kernel 54.34 (5.2.2021) AmigaOne X5000 release
Machine model: 9 (AmigaOne X5000/20)
Dump of context at 0xEFDB9BA0
Trap type: DSI exception
DSISR: 00800000  DAR: 61978260
Page: 0xEFAEDE40 (Virtual: 0x61978000, Physical: 0x00000000, Flags: 0x 800)
Machine State (raw): 0x0002F030
Machine State (verbose): [Critical Ints on] [ExtInt on] [User] [IAT on] [DAT on]
Instruction pointer: 0x7EE8D820
Crashed process: gorynlich (0x66DDB320)
DSI verbose error description: Access to address 0x61978260 not allowed by page protection in user state (protection violation)
Access was a store operation
Exception Syndrome Register: 0x00800000
 0: FFFEDF30 6198A330 00000002 475CC708 477492B0 01826C00 00001B9A 5158DD82
 8: 606554C2 5AB00000 00000001 000000F0 6198A330 5ABBF63C 00000000 6028AE10
16: 5AAF8624 475CC708 60743E10 5AAF863C 602BAE10 00000001 000078F0 0037EF00
24: 60641608 5AAF8398 00000001 5AAF8384 00000001 0000004A 477492B0 5AAD65A4
CR: 35553335   XER: A000007E  CTR: 01C1569C  LR: 7EE76CBC

Stack trace:
(0x6198A330) [thing_teleport.c:15] gorynlich:thing_reached_teleport()+0x10 (section 1 @ 0xBC81C)
(0x6198A3D0) [thing_collision.c:552] gorynlich:thing_handle_collisions()+0xe80 (section 1 @ 0xA5CB8)
(0x6198A470) [sdl.c:1517] gorynlich:sdl_loop()+0x740 (section 1 @ 0x613FC)
(0x6198ACB0) [main.c:869] gorynlich:main()+0xb58 (section 1 @ 0x2E9EC)
(0x6198AD10) native kernel module newlib.library.kmod+0x00002614
(0x6198AD60) native kernel module newlib.library.kmod+0x00003340
(0x6198AF10) native kernel module newlib.library.kmod+0x00003864
(0x6198AF40) gorynlich:_start()+0x1e0 (section 1 @ 0x1B3C)
(0x6198AF90) native kernel module dos.library.kmod+0x0002a490
(0x6198AFC0) native kernel module kernel+0x0005c6c8
(0x6198AFD0) native kernel module kernel+0x0005c740

Disassembly of crash site:
 7EE8D810: 3C00FFFE   lis               r0,-2
 7EE8D814: 7C2C0B78   mr                r12,r1
 7EE8D818: 6000DF30   ori               r0,r0,57136
 7EE8D81C: 3D205AB0   lis               r9,23216
>7EE8D820: 7C21016E   stwux             r1,r1,r0
 7EE8D824: 7C0802A6   mflr              r0
 7EE8D828: 92ACFFC4   stw               r21,-60(r12)
 7EE8D82C: 7C751B78   mr                r21,r3
 7EE8D830: 92ECFFCC   stw               r23,-52(r12)
 7EE8D834: 3869BDA0   subi              r3,r9,16992
Stack pointer (0x6198A330) is inside bounds

you could try to turn on this

Added that together with verify(t) and verify(teleport).

And then, when I start level, I have quite a bit of "ERROR: null pointer", but no crashes, the game starts as before. Then, once the time comes for teleport thing, I again crash on the same place in the code, at the beginning of the void thing_reached_teleport (thingp t, thingp teleport), stack trace even point out on the {. After crash happens, if I choose to ignore that crash, I have in the console:

"ERROR: **NULL POINTER* 0x0 thing.h:():1280

but that error can be because of a previous crash of course ..

[goblinhack]

can you send the stack trace?

does it crash now on the verify()s perhaps ?

is 1280 this ?

static inline uint8_t thing_is_dead (thingp t) { verify(t);

return (t->is_dead);

}

if so that would crash if t was null - does the traceback give a clue as to the caller of thing_is_dead ?

and the log output might give some clues. You could also add some more LOG()s into that crashing function to try and narrow it down LOG("%s %d",FUNCTION,LINE) kind of thing

On Wed, 31 Mar 2021 at 22:09, kas1e @.***> wrote:

@goblinhack https://github.com/goblinhack

I'm guessing maybe 't" is freed after the collision check below? any more info with gdb?

If only we have working gdb :) We have some sort of dump-info when a crash happens, it just shows the register's state, stack trace, etc, and can bring some light on, but not as good as gdb of course.

you could try to turn on this

Added that together with verify(t) and verify(teleport).

When I start level, I have quite a bit of "ERROR: null pointer", but no crashes, the game starts as before. Then, once time comes for teleport, I again crash on the same place (at the beginning of the void thing_reached_teleport (thingp t, thingp teleport), stack trace even point out on the {. After of crash if I ignore that crash, I have in the console:

"ERROR: *NULL POINTER 0x0 thing.h:():1280

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ptitSeb/gorynlich/issues/1#issuecomment-811466969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADA3H7Q7P36UYM6JI7NHHDTGOFQPANCNFSM4ILEYH7A .

[kas1e]

@goblinhack

can you send the stack trace?

Of course, its on the previous post :) There is relevant part:

Stack trace:
(0x6198A330) [thing_teleport.c:15] gorynlich:thing_reached_teleport()+0x10 (section 1 @ 0xBC81C)
(0x6198A3D0) [thing_collision.c:552] gorynlich:thing_handle_collisions()+0xe80 (section 1 @ 0xA5CB8)
(0x6198A470) [sdl.c:1517] gorynlich:sdl_loop()+0x740 (section 1 @ 0x613FC)
(0x6198ACB0) [main.c:869] gorynlich:main()+0xb58 (section 1 @ 0x2E9EC)

does it crash now on the verify()s perhaps? is 1280 this?

Yeah, line 1280 is verify(t);

Will try to add more debug today

[kas1e]

@goblinhack

Commenting out verify(t); on line 1280, didn't fix a crash. It instead starts to say that we have BAD POINTER in things_tp():904.

But crash happens early, before those output lines arise, much early. Just when we call [thing_collision.c:552] gorynlich:thing_handle_collisions() it then crash.

I may try to rebuild the game via GCC 10.0.1 instead of 8.4.0, maybe it will give us some more clue.

[goblinhack]

try this change to find who is calling thing_is_dead()

diff --git a/src/thing.h b/src/thing.h index f7145324..c9b73e1a 100755 --- a/src/thing.h +++ b/src/thing.h @@ -1275,8 +1275,14 @@ static inline uint8_t thing_is_dead_or_dying (thingp t) return (t->is_dead || thing_is_dying(t)); }

-static inline uint8_t thing_is_dead (thingp t) +#define thing_is_dead(t) thing_isdead(t, FUNCTION, LINE) + +static inline uint8_t thing_isdead (thingp t, char * func, int log) {

• if (!t) {
• ERR("NULL thing called from %s:%d:", func, log);
• abort(); // force a crash to get a traceback

• } verify(t);

  return (t->is_dead); diff --git a/src/thing_collision.c b/src/thing_collision.c index 93d1c758..ce1448e2 100755 --- a/src/thing_collision.c +++ b/src/thing_collision.c @@ -450,6 +450,9 @@ static void thing_handle_collision (thingp me, thingp it, int32_t x, int32_t y, int32_t dx, int32_t dy) {

• verfiy(me);
• verfiy(it);

• /*

  • Filter out boring things. / @@ -997,6 +1000,7 @@ LOG("add poss me %s hitter %s",thing_logname(me), thing_logname(it)); / void thing_handle_collisions (widp grid, thingp me) {

• verify(me); int32_t dx, dy;

  if (thing_has_left_level(me)) { @@ -1035,6 +1039,10 @@ LOG("shield coll"); } else { it = thing_client_id(cell->id[i]); }

• if (!it) {
• continue;

• }

  if 0

  if (debug) { LOG("%d %d [%d] %s",x,y,i, thing_logname(it)); diff --git a/src/thing_teleport.c b/src/thing_teleport.c index 74fd3782..1908b540 100755 --- a/src/thing_teleport.c +++ b/src/thing_teleport.c @@ -12,6 +12,9 @@

  void thing_reached_teleport (thingp t, thingp teleport) {

• verify(t);
• verify(teleport);

• int tx[MAP_WIDTHMAP_HEIGHT]; int ty[MAP_WIDTHMAP_HEIGHT]; int poss = 0;

On Thu, 1 Apr 2021 at 06:54, kas1e @.***> wrote:

@goblinhack https://github.com/goblinhack

Commenting out verify(t); on line 1280, didn't fix a crash. It instead starts to say that we have BAD POINTER in things_tp():904.

But crash happens early, before those output lines arise, much early. Just when we call [thing_collision.c:552] gorynlich:thing_handle_collisions() it then crash.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ptitSeb/gorynlich/issues/1#issuecomment-811663077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADA3HZQNOCYGEYGUMA6WDTTGQDAXANCNFSM4ILEYH7A .

[kas1e]

@goblinhack Thanks for the help :) Firstly tried this path without ENABLE_PTRCHECK - nope, nothing on the console. It the same crashes, with the same crash log, and nothing in the console before or after a crash happens.

Next, I tried this patch with enabled ENABLE_PTRCHECK, this time as always when I start level I have lots of "NULL POINTER" errors, and when it calls thing_reached_teleport() it crashes. After the crash happens, I have lots of bad_pointer errors, but they all happen after the crash. So can be just a side-effect. But the log looks like this:

00:00:27.350: ERROR: null pointer
00:00:27.350: ERROR: null pointer
00:00:27.358: ERROR: null pointer
00:00:27.358: ERROR: null pointer
00:00:27.365: ERROR: null pointer
00:00:27.365: ERROR: null pointer
00:00:30.689: Server: Level 0.0[0x47836008] (server): Reset players at start of level
00:00:30.691: Server: Level 0.0[0x47836008] (server): level loaded
00:00:30.693: Server: Level 0.0[0x47836008] (server): Allocate trigger, white
00:00:30.696: Server: Level 0.0[0x47836008] (server): No action trigger exists, activate trigger, white
00:00:30.698: Server: Level 0.0[0x47836008] (server): Activate trigger, white
00:00:31.197: Client: Level 1.2[0x43265008] (client): created
00:00:51.233: ERROR: **BAD POINTER** 0x5adb0000 :():1288
00:00:51.233: ERROR: **BAD POINTER** 0x5adb0000 :():1288
00:00:51.259: DYING: Died at ptrcheck.c:ptrcheck_verify_pointer():449
00:00:51.261: FATAL ERROR: Fatal error
00:00:51.263: ERROR: FATAL ERROR: Fatal error
00:00:51.263: ERROR: FATAL ERROR: Fatal error
00:00:51.741: Client: Level 1.2[0x43265008] (client): destroy
00:00:51.750: Client: Level 1.2[0x43265008] (client): destroyed
00:00:51.771: Server: Level 0.0[0x47836008] (server): destroy things and players
00:00:52.049: Server: Level 0.0[0x47836008] (server): destroy
00:00:52.051: Server: Level 0.0[0x47836008] (server): destroyed
exit(1) error
LIBGL: Shuting down 

and 1288 line, is our verify(t);.

It all looks like that "things_is_dead" is not the one we have issues with. It just after we crash, things continue to be bad for this part, but the original issue a bit early: when thing_reach_teleport. I.e. when we call thing_reached_teleport(me, it); from the things_collision.c

[kas1e]

@goblinhack Intersting that if i do in the things_collision.c just that:

        if (thing_is_teleport(it)) {
            LOG("thing reached teleport bliad !!!\n");
            //thing_reached_teleport(me, it);
            return;
        }

I.e. comment outcall to thing_reached_Teleport(), but instead put LOG, then I never crashes, but I also never see a LOG printf ! Wtf :)

[goblinhack]

I'm confused why you don't see function and file output in the error - look at ptrcheck.h

define PTRCHECK_AT FILE, FUNCTION, LINE

this macro should be expanding and giving you info but I see "()" for FUNCTION above

a long shot - you did a make clean when turningon ENABLE_PTRCHECK ?

you can also do this

diff --git a/src/ptrcheck.c b/src/ptrcheck.c index 51f653d9..2ab70788 100755 --- a/src/ptrcheck.c +++ b/src/ptrcheck.c @@ -466,7 +466,7 @@ void ptrcheck_alloc (const void ptr, ptrcheck *context;

 if (!ptr) {

• ERR("null pointer");

• ERR("null pointer %s:%s():%u", file, func, line); }

  / @@ -544,7 +544,7 @@ uint8_t ptrcheck_free (void ptr, ptrcheck *context;

  if (!ptr) {

• ERR("null pointer");

• ERR("null pointer %s:%s():%u", file, func, line);

   return (false);;

  }

but if FILE and FUNCTION don't expand with your compiler then I'm confused

On Thu, 1 Apr 2021 at 08:51, kas1e @.***> wrote:

@goblinhack https://github.com/goblinhack Intersting that if i do in the things_collision.c just that:

    if (thing_is_teleport(it)) {
      LOG("thing reached teleport bliad !!!\n");
        //thing_reached_teleport(me, it);
        return;
    }

I.e. comment outcall to thing_reached_Teleport(), but instead put LOG, then I never crashes, but I also never see a LOG printf ! Wtf :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ptitSeb/gorynlich/issues/1#issuecomment-811720667, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADA3H6EZA7EZFONIMJUHGLTGQQZJANCNFSM4ILEYH7A .

[kas1e]

@goblinhack

this macro should be expanding and giving you info but I see "()" for FUNCTION above

Maybe that because you have in patch "char " for function, while it asks to be "cost chat "?

a long shot - you did a make clean when turning on ENABLE_PTRCHECK?

Yes, tried again with the full clean rebuild with adding ERR("null pointer %s:%s():%u", file, func, line); parts into the ptrcheck.c as well, and there is the full log:

00:00:32.565: Server: Level 0.0[0x4d410008] (server): Activate trigger, white
00:00:33.081: Client: Level 1.2[0x4272d008] (client): created
00:00:52.080: Client: Level 1.2[0x4272d008] (client): destroy
00:00:52.082: Client: Level 1.2[0x4272d008] (client): destroyed
00:00:53.888: Server: Level 0.0[0x4d410008] (server): destroy things and players
00:00:54.162: Server: Level 0.0[0x4d410008] (server): destroy
00:00:54.166: Server: Level 0.0[0x4d410008] (server): destroyed
00:00:57.315: Server: Level 0.0[0x4272d008] (server): created
00:00:57.316: Server: Level 0.0[0x4272d008] (server): Level generating
00:00:57.324: ERROR: null pointer dungeon_resize_jigpiece:map_jigsaw.c():302
00:00:57.324: ERROR: null pointer dungeon_resize_jigpiece:map_jigsaw.c():302
00:00:57.342: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.342: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.358: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.358: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.374: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.374: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.389: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.389: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.405: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.405: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.420: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.420: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.436: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.436: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.451: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.451: ERROR: null pointer dungeon_resize_frag:map_jigsaw.c():313
00:00:57.467: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.467: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.484: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.484: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.500: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.500: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.517: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.517: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.533: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.533: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.563: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.563: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.579: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.579: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.596: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.596: ERROR: null pointer dungeon_resize_frag_alt:map_jigsaw.c():325
00:00:57.633: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.633: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.652: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.652: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.672: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.672: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.693: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.693: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.713: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.713: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.732: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.732: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.751: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.751: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.771: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.771: ERROR: null pointer dungeon_resize_trigger_fragment:map_jigsaw.c():337
00:00:57.790: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.790: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.807: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.807: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.823: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.823: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.840: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.840: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.856: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.856: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.872: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.872: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.889: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.889: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.905: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.905: ERROR: null pointer dungeon_resize_trigger:map_jigsaw.c():349
00:00:57.922: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.922: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.938: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.938: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.954: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.954: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.971: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.971: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.987: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:57.987: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.003: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.003: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.020: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.020: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.036: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.036: ERROR: null pointer dungeon_resize_action1:map_jigsaw.c():361
00:00:58.053: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.053: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.069: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.069: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.086: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.086: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.102: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.102: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.118: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.118: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.135: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.135: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.151: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.151: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.167: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.167: ERROR: null pointer dungeon_resize_action2:map_jigsaw.c():373
00:00:58.184: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.184: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.200: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.200: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.217: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.217: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.234: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.234: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.250: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.250: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.267: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.267: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.283: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.283: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.299: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:58.299: ERROR: null pointer dungeon_resize_action3:map_jigsaw.c():385
00:00:59.998: Server: Level 0.0[0x4272d008] (server): Reset players at start of level
00:01:00.000: Server: Level 0.0[0x4272d008] (server): level loaded
00:01:00.002: Server: Level 0.0[0x4272d008] (server): Allocate trigger, white
00:01:00.005: Server: Level 0.0[0x4272d008] (server): No action trigger exists, activate trigger, white
00:01:00.007: Server: Level 0.0[0x4272d008] (server): Activate trigger, white
00:01:00.716: Client: Level 1.3[0x4d410008] (client): created
00:01:09.747: ERROR: **BAD POINTER** 0x5abf0000 :():1288
00:01:09.747: ERROR: **BAD POINTER** 0x5abf0000 :():1288
00:01:09.782: DYING: Died at ptrcheck.c:ptrcheck_verify_pointer():449
00:01:09.784: FATAL ERROR: Fatal error
00:01:09.786: ERROR: FATAL ERROR: Fatal error
00:01:09.786: ERROR: FATAL ERROR: Fatal error
00:01:10.181: Client: Level 1.3[0x4d410008] (client): destroy
00:01:10.183: Client: Level 1.3[0x4d410008] (client): destroyed
00:01:10.205: Server: Level 0.0[0x4272d008] (server): destroy things and players
00:01:10.529: Server: Level 0.0[0x4272d008] (server): destroy
00:01:10.532: Server: Level 0.0[0x4272d008] (server): destroyed
exit(1) error
LIBGL: Shuting down 

See, at first it bring lots of null pointers from map_jigsaw.c , then when we had teleport call we then crash with bad_pointer.

[kas1e]

As I see from the code, all those null-pointers when the level starts come from myrealloc calls. Maybe because of them we crash on teleport_thing later?

[goblinhack]

is it possible to checkout the change prior to the map jigsaw changes and see if that introduced the crash - as this is a new crash, right ? it might be memory corruption

these null pointer warnings might be harmless - but I think we need to narrow down when this broke - if there have been recent changes...

On Thu, 1 Apr 2021 at 09:19, kas1e @.***> wrote:

As I see from the code, all those null-pointers when the level starts come from myrealloc calls. Maybe because of them we crash on teleport_thing later?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ptitSeb/gorynlich/issues/1#issuecomment-811737499, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADA3H3QP55PAFG6OVAP3A3TGQUADANCNFSM4ILEYH7A .

[kas1e]

Yeah, will check. Anyway, what I think that maybe for the first amigaos4 release just comment out calling to thing_reached_teleport(me, it); and be done with it? Or it will break the game's functionality a lot?