Segmentation fault in UpdateRect function

Hello all, first time poster but long time supporter and programmer of SDL. I have been away from graphics programming for a while. But I came back to SDL and after a few days or reacquainting myself with the library, I feel I have a basic grasp of it.

My question for all you developers out there is in regards to a simple game engine I just coded. As of now it is still error prone and not perfect, but I am working on it. My main concern is that whenever I run my program, it seems to work fine and even displays a bitmap image I loaded. However, upon exiting I get a segmentation fault in my console. I didn’t think this would affect my program, but when I try to move my bitmap interactively (in response to keyboard presses), nothing happens. After running the GNU debugger, I get this output:

Code:

Program received signal SIGSEGV, Segmentation fault.
0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
(gdb) where
#0 0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
#1 0x0015fbe1 in SDL_UpdateRect () from /usr/lib/libSDL-1.2.so.0
#2 0x08048cb4 in updateScreen ()
#3 0x08048eb7 in main ()

My code is quite long so for now I will post my screen update function. If more is required I will be glad to post the whole code if that will help.

Note that screen and buffer were previously initialized as SDL_Surface and unsigned char*, respectively.

Code:

void updateScreen()
{
unsigned char *p;
/lock screen and copy buffer to it/
SDL_LockSurface(screen);

p = (unsigned char*)screen->pixels;
memcpy(p, buffer, scr_w * scr_h);	

SDL_UnlockSurface(screen);

SDL_UpdateRect(screen, 0, 0, 0, 0);

}

What are you trying to do with this function? It takes care to mess with
the ‘pixels’ member of SDL_Surface. You should not have to do anything to
it unless you’re writing your own loader, blitter, or primitives.
SDL_Surfaces represent graphical buffers in SDL and are typically
manipulated with SDL_BlitSurface().

As for the things I notice here… You are assuming that the pixels are
arranged in a scr_w x scr_h rectangle. This might not be true depending on
the ‘pitch’ member. Also, you are assuming that the data is stored as
single bytes (unsigned char). You have not indicated that you know this
about your surface. The ‘format’ member has ‘BytesPerPixel’ that might not
be 1. In modern SDL, it is usually 24 or 32 bit (3 or 4 bytes) per pixel.

I haven’t ever tried using memcpy on a surface, but it might have to look
more like this:
memcpy(p, buffer, (scr_w + screen->pitch)*scr_h *
screen->format->BytesPerPixel);

Make sure ‘buffer’ has the right amount of space, of course.

I don’t know if this fixes anything, but good luck anyhow.

Jonny DOn Thu, Dec 29, 2011 at 11:07 PM, robhilly wrote:

**
Hello all, first time poster but long time supporter and programmer of
SDL. I have been away from graphics programming for a while. But I came
back to SDL and after a few days or reacquainting myself with the library,
I feel I have a basic grasp of it.

My question for all you developers out there is in regards to a simple
game engine I just coded. As of now it is still error prone and not
perfect, but I am working on it. My main concern is that whenever I run my
program, it seems to work fine and even displays a bitmap image I loaded.
However, upon exiting I get a segmentation fault in my console. I didn’t
think this would affect my program, but when I try to move my bitmap
interactively (in response to keyboard presses), nothing happens. After
running the GNU debugger, I get this output:

Code:

Program received signal SIGSEGV, Segmentation fault.
0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
(gdb) where
#0 0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
#1 0x0015fbe1 in SDL_UpdateRect () from /usr/lib/libSDL-1.2.so.0
#2 0x08048cb4 in updateScreen ()
#3 0x08048eb7 in main ()

My code is quite long so for now I will post my screen update function. If
more is required I will be glad to post the whole code if that will help.

Quote:

Note that screen and buffer were previously initialized as SDL_Surfaceand unsigned
char*, respectively.

Code:

void updateScreen()
{
unsigned char *p;
/lock screen and copy buffer to it/
SDL_LockSurface(screen);

p = (unsigned char*)screen->pixels;
memcpy(p, buffer, scr_w * scr_h);

SDL_UnlockSurface(screen);

SDL_UpdateRect(screen, 0, 0, 0, 0);
}


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

A recent post on the list reminded me that pitch includes the width, duh.
So, remove the width from my memcpy call.

Jonny DOn Sat, Dec 31, 2011 at 9:18 AM, Jonathan Dearborn <@Jonathan_Dearborn>wrote:

What are you trying to do with this function? It takes care to mess with
the ‘pixels’ member of SDL_Surface. You should not have to do anything to
it unless you’re writing your own loader, blitter, or primitives.
SDL_Surfaces represent graphical buffers in SDL and are typically
manipulated with SDL_BlitSurface().

As for the things I notice here… You are assuming that the pixels are
arranged in a scr_w x scr_h rectangle. This might not be true depending on
the ‘pitch’ member. Also, you are assuming that the data is stored as
single bytes (unsigned char). You have not indicated that you know this
about your surface. The ‘format’ member has ‘BytesPerPixel’ that might not
be 1. In modern SDL, it is usually 24 or 32 bit (3 or 4 bytes) per pixel.

I haven’t ever tried using memcpy on a surface, but it might have to look
more like this:
memcpy(p, buffer, (scr_w + screen->pitch)*scr_h *
screen->format->BytesPerPixel);

Make sure ‘buffer’ has the right amount of space, of course.

I don’t know if this fixes anything, but good luck anyhow.

Jonny D

On Thu, Dec 29, 2011 at 11:07 PM, robhilly wrote:

**
Hello all, first time poster but long time supporter and programmer of
SDL. I have been away from graphics programming for a while. But I came
back to SDL and after a few days or reacquainting myself with the library,
I feel I have a basic grasp of it.

My question for all you developers out there is in regards to a simple
game engine I just coded. As of now it is still error prone and not
perfect, but I am working on it. My main concern is that whenever I run my
program, it seems to work fine and even displays a bitmap image I loaded.
However, upon exiting I get a segmentation fault in my console. I didn’t
think this would affect my program, but when I try to move my bitmap
interactively (in response to keyboard presses), nothing happens. After
running the GNU debugger, I get this output:

Code:

Program received signal SIGSEGV, Segmentation fault.
0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
(gdb) where
#0 0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
#1 0x0015fbe1 in SDL_UpdateRect () from /usr/lib/libSDL-1.2.so.0
#2 0x08048cb4 in updateScreen ()
#3 0x08048eb7 in main ()

My code is quite long so for now I will post my screen update function.
If more is required I will be glad to post the whole code if that will help.

Quote:

Note that screen and buffer were previously initialized as SDL_Surfaceand unsigned
char*, respectively.

Code:

void updateScreen()
{
unsigned char *p;
/lock screen and copy buffer to it/
SDL_LockSurface(screen);

p = (unsigned char*)screen->pixels;
memcpy(p, buffer, scr_w * scr_h);

SDL_UnlockSurface(screen);

SDL_UpdateRect(screen, 0, 0, 0, 0);
}


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You’re right about the pitch member. Funny thing is I had an instance where I was working with 8 bit surfaces and bitmaps. Upon loading one and attempting to draw it with Direct Surface editing, I discovered that the pitch member (even in a 1 byte pixel format) can be different than the width. The image I loaded had a width of 147 pixels. After loading it into a surface, the pitch member ended up being 148. Any idea why this difference would occur? Regardless, I got into the habit of using that pitch member instead of the surface width when directly accessing pixel rows.

Jonny D wrote:> A recent post on the list reminded me that pitch includes the width, duh. ?So, remove the width from my memcpy call.

Jonny D

On Sat, Dec 31, 2011 at 9:18 AM, Jonathan Dearborn <grimfang4 at gmail.com (grimfang4 at gmail.com)> wrote:

What are you trying to do with this function? ?It takes care to mess with the ‘pixels’ member of SDL_Surface. ?You should not have to do anything to it unless you’re writing your own loader, blitter, or primitives. ?SDL_Surfaces represent graphical buffers in SDL and are typically manipulated with SDL_BlitSurface().

As for the things I notice here… ?You are assuming that the pixels are arranged in a scr_w x scr_h rectangle. ?This might not be true depending on the ‘pitch’ member. ?Also, you are assuming that the data is stored as single bytes (unsigned char). ?You have not indicated that you know this about your surface. ?The ‘format’ member has ‘BytesPerPixel’ that might not be 1. ?In modern SDL, it is usually 24 or 32 bit (3 or 4 bytes) per pixel.

I haven’t ever tried using memcpy on a surface, but it might have to look more like this:
memcpy(p, buffer, (scr_w + screen->pitch)*scr_h * screen->format->BytesPerPixel);

Make sure ‘buffer’ has the right amount of space, of course.

I don’t know if this fixes anything, but good luck anyhow.

Jonny D

On Thu, Dec 29, 2011 at 11:07 PM, robhilly <@robhilly (@robhilly)> wrote:

   	Hello all, first time poster but long time supporter and programmer of SDL. I have been away from graphics programming for a while. But I came back to SDL and after a few days or reacquainting myself with the library, I feel I have a basic grasp of it.

My question for all you developers out there is in regards to a simple game engine I just coded. As of now it is still error prone and not perfect, but I am working on it. My main concern is that whenever I run my program, it seems to work fine and even displays a bitmap image I loaded. However, upon exiting I get a segmentation fault in my console. I didn’t think this would affect my program, but when I try to move my bitmap interactively (in response to keyboard presses), nothing happens. After running the GNU debugger, I get this output:

Code:

Program received signal SIGSEGV, Segmentation fault.
0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
(gdb) where
#0? 0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
#1? 0x0015fbe1 in SDL_UpdateRect () from /usr/lib/libSDL-1.2.so.0
#2? 0x08048cb4 in updateScreen ()
#3? 0x08048eb7 in main ()

My code is quite long so for now I will post my screen update function. If more is required I will be glad to post the whole code if that will help.

Quote:

Note that screen and buffer were previously initialized as SDL_Surface and unsigned char*, respectively.







Code:

void updateScreen()
{
? ?unsigned char p;
? ?/lock screen and copy buffer to it/
? ?SDL_LockSurface(screen);
? ?
? ?p = (unsigned char
)screen->pixels;
? ?memcpy(p, buffer, scr_w * scr_h);? ?

? ?SDL_UnlockSurface(screen);

? ?SDL_UpdateRect(screen, 0, 0, 0, 0);
}


SDL mailing list
SDL at lists.libsdl.org (SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org (http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

As far as I know, the pitch member represents SDL trying to pack the data
in a way that might be more efficiently accessed by the CPU or other
hardware. It might also help with some of the blitting algorithms to have
even numbers of bits or words or whatever. Here’s one way of finding out:
grep -rn “pitch.*=” *

i.e. if you really want to know, looking at SDL’s code would probably
enlighten us.

Jonny DOn Tue, Jan 3, 2012 at 10:36 PM, robhilly wrote:

**
You’re right about the pitch member. Funny thing is I had an instance
where I was working with 8 bit surfaces and bitmaps. Upon loading one and
attempting to draw it with Direct Surface editing, I discovered that the
pitch member (even in a 1 byte pixel format) can be different than the
width. The image I loaded had a width of 147 pixels. After loading it into
a surface, the pitch member ended up being 148. Any idea why this
difference would occur? Regardless, I got into the habit of using that
pitch member instead of the surface width when directly accessing pixel
rows.

Jonny D wrote:

A recent post on the list reminded me that pitch includes the width,
duh. So, remove the width from my memcpy call.

Jonny D

On Sat, Dec 31, 2011 at 9:18 AM, Jonathan Dearborn <> wrote:

Quote:

What are you trying to do with this function? It takes care to mess
with the ‘pixels’ member of SDL_Surface. You should not have to do
anything to it unless you’re writing your own loader, blitter, or
primitives. SDL_Surfaces represent graphical buffers in SDL and are
typically manipulated with SDL_BlitSurface().

As for the things I notice here… You are assuming that the pixels are
arranged in a scr_w x scr_h rectangle. This might not be true depending on
the ‘pitch’ member. Also, you are assuming that the data is stored as
single bytes (unsigned char). You have not indicated that you know this
about your surface. The ‘format’ member has ‘BytesPerPixel’ that might not
be 1. In modern SDL, it is usually 24 or 32 bit (3 or 4 bytes) per pixel.

I haven’t ever tried using memcpy on a surface, but it might have to look
more like this:
memcpy(p, buffer, (scr_w + screen->pitch)*scr_h *
screen->format->BytesPerPixel);

Make sure ‘buffer’ has the right amount of space, of course.

I don’t know if this fixes anything, but good luck anyhow.

Jonny D

On Thu, Dec 29, 2011 at 11:07 PM, robhilly <> wrote:

Quote:

Hello all, first time poster but long time supporter and programmer of
SDL. I have been away from graphics programming for a while. But I came
back to SDL and after a few days or reacquainting myself with the library,
I feel I have a basic grasp of it.

My question for all you developers out there is in regards to a simple
game engine I just coded. As of now it is still error prone and not
perfect, but I am working on it. My main concern is that whenever I run my
program, it seems to work fine and even displays a bitmap image I loaded.
However, upon exiting I get a segmentation fault in my console. I didn’t
think this would affect my program, but when I try to move my bitmap
interactively (in response to keyboard presses), nothing happens. After
running the GNU debugger, I get this output:

Code:

Program received signal SIGSEGV, Segmentation fault.
0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
(gdb) where
#0 0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
#1 0x0015fbe1 in SDL_UpdateRect () from /usr/lib/libSDL-1.2.so.0
#2 0x08048cb4 in updateScreen ()
#3 0x08048eb7 in main ()

My code is quite long so for now I will post my screen update function. If
more is required I will be glad to post the whole code if that will help.

Quote:

Note that screen and buffer were previously initialized as SDL_Surface and
unsigned char*, respectively.

Code:

void updateScreen()
{
unsigned char *p;
/lock screen and copy buffer to it/
SDL_LockSurface(screen);

p = (unsigned char*)screen->pixels;
memcpy(p, buffer, scr_w * scr_h);

SDL_UnlockSurface(screen);

SDL_UpdateRect(screen, 0, 0, 0, 0);
}


SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

**
You’re right about the pitch member. Funny thing is I had an instance
where I was working with 8 bit surfaces and bitmaps. Upon loading one and
attempting to draw it with Direct Surface editing, I discovered that the
pitch member (even in a 1 byte pixel format) can be different than the
width. The image I loaded had a width of 147 pixels. After loading it into
a surface, the pitch member ended up being 148. Any idea why this
difference would occur? Regardless, I got into the habit of using that
pitch member instead of the surface width when directly accessing pixel
rows.

Yes, 148 happens to be a multiple of 4 (i.e. 32 bits). If the computer can
copy larger blocks, say 4 bytes at a time, then it will generally be faster
than copying 1 byte blocks. There are other reasons too. A lot of hardware
(RISC CPUs, for example) discard* the lowest 2 bits of the address when
reading a 32-bit value from memory (i.e. memory addresses are expected to
be a multiple of 4, or aligned to the 4th byte). This allows simpler and/or
faster hardware. 147 is an awkward number since the first row of pixels
could begin on an aligned address like 0x1000 and end on an unaligned
address like 0x01093 (which would actually crash them). Generally, if you
begin a row on an aligned address, you want the next row to begin on an
aligned address as well. Some GPUs require even stricter alignment, like
alignment of 64 bytes or that an image must be a multiple of 64KB.

Patrick

  • Really, they trap if the bits are non-zero to signal a program error. The
    kernel sends a SIGBUS to your process and it dies, generally. The hardware
    still doesn’t support unaligned accesses.On Tue, Jan 3, 2012 at 9:36 PM, robhilly wrote:

Jonny D wrote:

A recent post on the list reminded me that pitch includes the width,
duh. So, remove the width from my memcpy call.

Jonny D

On Sat, Dec 31, 2011 at 9:18 AM, Jonathan Dearborn <> wrote:

Quote:

What are you trying to do with this function? It takes care to mess
with the ‘pixels’ member of SDL_Surface. You should not have to do
anything to it unless you’re writing your own loader, blitter, or
primitives. SDL_Surfaces represent graphical buffers in SDL and are
typically manipulated with SDL_BlitSurface().

As for the things I notice here… You are assuming that the pixels are
arranged in a scr_w x scr_h rectangle. This might not be true depending on
the ‘pitch’ member. Also, you are assuming that the data is stored as
single bytes (unsigned char). You have not indicated that you know this
about your surface. The ‘format’ member has ‘BytesPerPixel’ that might not
be 1. In modern SDL, it is usually 24 or 32 bit (3 or 4 bytes) per pixel.

I haven’t ever tried using memcpy on a surface, but it might have to look
more like this:
memcpy(p, buffer, (scr_w + screen->pitch)*scr_h *
screen->format->BytesPerPixel);

Make sure ‘buffer’ has the right amount of space, of course.

I don’t know if this fixes anything, but good luck anyhow.

Jonny D

On Thu, Dec 29, 2011 at 11:07 PM, robhilly <> wrote:

Quote:

Hello all, first time poster but long time supporter and programmer of
SDL. I have been away from graphics programming for a while. But I came
back to SDL and after a few days or reacquainting myself with the library,
I feel I have a basic grasp of it.

My question for all you developers out there is in regards to a simple
game engine I just coded. As of now it is still error prone and not
perfect, but I am working on it. My main concern is that whenever I run my
program, it seems to work fine and even displays a bitmap image I loaded.
However, upon exiting I get a segmentation fault in my console. I didn’t
think this would affect my program, but when I try to move my bitmap
interactively (in response to keyboard presses), nothing happens. After
running the GNU debugger, I get this output:

Code:

Program received signal SIGSEGV, Segmentation fault.
0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
(gdb) where
#0 0x0015f8f0 in SDL_UpdateRects () from /usr/lib/libSDL-1.2.so.0
#1 0x0015fbe1 in SDL_UpdateRect () from /usr/lib/libSDL-1.2.so.0
#2 0x08048cb4 in updateScreen ()
#3 0x08048eb7 in main ()

My code is quite long so for now I will post my screen update function. If
more is required I will be glad to post the whole code if that will help.

Quote:

Note that screen and buffer were previously initialized as SDL_Surface and
unsigned char*, respectively.

Code:

void updateScreen()
{
unsigned char *p;
/lock screen and copy buffer to it/
SDL_LockSurface(screen);

p = (unsigned char*)screen->pixels;
memcpy(p, buffer, scr_w * scr_h);

SDL_UnlockSurface(screen);

SDL_UpdateRect(screen, 0, 0, 0, 0);
}


SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org