SDL segmentation fault and image corruptions

sparker · 04-01-2008, 01:53 PM

Basically I have two problems. I'm currently developing a networked pong game using SDL and C with my class at college. It has the functionality to support up to 16 players in a single game, but issues are arising which causes the program to crash at random times and some images get messed up when new players join.

Okay first the program crashes randomly after like 5 minutes to 1 hour when SDL_UpperBlit is called like so:

Code:

#define MAX_BLITS	34

struct blit {
        SDL_Surface *src;
        SDL_Rect *srcrect;
        SDL_Rect *dstrect;
} blits[MAX_BLITS];

void update_screen(void)
{
        int i;
        for (i = 0; i < numupdates; ++i) {
		if (blits[i].src == 0 || blits[i].srcrect == 0 ||
			screen == 0 || blits[i].dstrect == 0) {
			continue;
		}			
                SDL_UpperBlit(blits[i].src, blits[i].srcrect, screen,
                              blits[i].dstrect);
        }
        SDL_UpdateRects(screen, numupdates, dstupdate);
        numupdates = 0;
}

The design of the program is that each client loads a ball image, two white paddles (horizontal and vertical) and one red paddle they control (horizontal or vertical). The server assigns players a side based on the order they join. Each player sends its paddle to the server. The server sends all paddles out to the players and they assign the appropriate image to draw based on the index in an array like so:

Code:

if (ball.alive) {
        for (j = 0; j < players; j++) {
                if (j != get_client_pos()) {
                        p = get_paddle(j);

                        if (j == 0 || j == 1 || j == 4
			|| j == 5 || j == 8 || j == 9
			|| j == 12 || j == 13)
                                p.image = *other_vert;
                        else
                                p.image = *other_horz;

                        if (p.alive)
                                draw_object(&p);

                        tmp[j] = p;
                }
        }
        send_paddle(player, server_ip);
        draw_object(&player);
        draw_object(&ball);
}

The problem is when a third person joins the vertical white paddle on player one and player two's opposite side shrinks in height to the point where it is as small as the ball. And the third person sees all paddles fine.

Anyways any suggestions towards either problem would help greatly.

SciYro · 04-01-2008, 04:37 PM

oowwe, my eyes.... sooo many hard coded numbers, and all packed together without comments... Not that it matters, doesn't seem to be anything interesting in that code anyways, nothing i can see to cause a error.

Have you tried just stepping thru program in a debugger like ddd? First, i would recommend a good pass thru valgrind, seems like a memory problem is a good place to start.

sparker · 04-01-2008, 05:28 PM

I've just started running valgrind on it. From what it seems about 3/4 of the memory allocated is not being freed. The output of any real reference to the update_screen() function was:

Code:

==25943== 2,204 bytes in 1 blocks are still reachable in loss record 148 of 186
==25943==    at 0x4A05AF7: realloc (vg_replace_malloc.c:306)
==25943==    by 0x34D7015510: (within /usr/lib64/libSDL-1.2.so.0.11.1)
==25943==    by 0x34D701673B: (within /usr/lib64/libSDL-1.2.so.0.11.1)
==25943==    by 0x34D702A465: (within /usr/lib64/libSDL-1.2.so.0.11.1)
==25943==    by 0x34D702B61F: SDL_LowerBlit (in /usr/lib64/libSDL-1.2.so.0.11.1)
==25943==    by 0x34D702B861: SDL_UpperBlit (in /usr/lib64/libSDL-1.2.so.0.11.1)
==25943==    by 0x403B80: update_screen (in /root/Desktop/pong_version_9_laverne/client)
==25943==    by 0x403373: game (game.c:202)
==25943==    by 0x403994: game_start (game.c:52)
==25943==    by 0x402A79: on_start_button_clicked (main_window.c:267)
==25943==    by 0x34C6C0B1A8: g_closure_invoke (in /lib64/libgobject-2.0.so.0.1400.4)
==25943==    by 0x34C6C1A830: (within /lib64/libgobject-2.0.so.0.1400.4)

And the summary was:

Code:

==25943== LEAK SUMMARY:
==25943==    definitely lost: 18,404 bytes in 51 blocks.
==25943==    indirectly lost: 28,192 bytes in 881 blocks.
==25943==      possibly lost: 164,704 bytes in 889 blocks.
==25943==    still reachable: 2,269,132 bytes in 17,251 blocks.
==25943==         suppressed: 0 bytes in 0 blocks.

Sorry about the code quality here, were only second year students, so we don't have a whole lot of actual experience working on bigger projects.

SciYro · 04-01-2008, 05:52 PM

Ummm, just to be clear, you recreated the error in valgrind? Because its nice to have memory friendly code and all, but using valgrind instead of a debugger is so its possible to see if memory is getting corrupted around the time of the error.