Mysterious SIGSEGV in static structure initialization

SDL Development
1

Hello!

I am using a graphics library which uses SDL2.0 as backend. It crashes in
invocation of SDL_RenderFillRect, on initialization of local SDL_Rect.

SDL_RenderFillRect(SDL_Renderer * renderer, const SDL_Rect * rect)
{
SDL_Rect full_rect = { 0, 0, 0, 0 };

CHECK_RENDERER_MAGIC(renderer, -1);

(…)

I find it very weird. Furthermore, the segmentation violation happens only
if the library is called from program in D or Free Pascal. When called
from Python 2, C or Java program it does not occur.

Replacing the initializer with call to memset fixes the problem (there are
two more such places in src/render/SDL_render.c), so with slightly altered
build of SDL2.0.3 I can proceed with development of my game in D. However,
I really would like to learn the cause of this segfault. Checking stack
size did not help - apparently there is enough space in all cases. Has
anyone encountered this problem before? What can I do to dig further?

2

If you’re using Linux, try running your program through Valgrind. On
Windows, Dr. Memory might work for you. When you change something that
wouldn’t seem to change anything but actually does, suspect memory bugs.

Jonny DOn Sat, Oct 31, 2015 at 11:34 AM, “Micha? Bieli?ski” wrote:

Hello!

I am using a graphics library which uses SDL2.0 as backend. It crashes in
invocation of SDL_RenderFillRect, on initialization of local SDL_Rect.

SDL_RenderFillRect(SDL_Renderer * renderer, const SDL_Rect * rect)
{
SDL_Rect full_rect = { 0, 0, 0, 0 };

CHECK_RENDERER_MAGIC(renderer, -1);

(…)

I find it very weird. Furthermore, the segmentation violation happens only
if the library is called from program in D or Free Pascal. When called
from Python 2, C or Java program it does not occur.

Replacing the initializer with call to memset fixes the problem (there are
two more such places in src/render/SDL_render.c), so with slightly altered
build of SDL2.0.3 I can proceed with development of my game in D. However,
I really would like to learn the cause of this segfault. Checking stack
size did not help - apparently there is enough space in all cases. Has
anyone encountered this problem before? What can I do to dig further?

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

3

I think this may be the most important part:

2015-10-31 12:34 GMT-03:00, “Micha? Bieli?ski” :

Furthermore, the segmentation violation happens only
if the library is called from program in D or Free Pascal. When called
from Python 2, C or Java program it does not occur.

Makes me wonder if there’s something wrong with the way the bindings work.

4

Dnia 31 Pa?dziernika 2015, 16:42, So, Jonathan Dearborn napisa?:

If you’re using Linux, try running your program through Valgrind. On
Windows, Dr. Memory might work for you. When you change something that
wouldn’t seem to change anything but actually does, suspect memory bugs.

I finally made some time for learning how to use Valgrind. Turns out it
is nowhere near as difficult as my imagination hinted. Unfortunately, it
did not help. I found about 5 kb of memory possibly lost but nothing
relating to the crash.

5

Dnia 31 Pa?dziernika 2015, 18:01, So, Sik the hedgehog napisa?:

I think this may be the most important part:

2015-10-31 12:34 GMT-03:00, “Micha? Bieli?ski” <@Michal_Bielinski>:

Furthermore, the segmentation violation happens only
if the library is called from program in D or Free Pascal.
When called from Python 2, C or Java program it does not occur.

Makes me wonder if there’s something wrong with the way the bindings work.

It might be the most important clue but are bindings really to blame?
Execution path of program looks roughly like this:

main (Pas/D) -> GUI lib (C++) -> SDL2

Anyway knowing what piece of code causes the crash allows me to stick it
to any place. I am going to see if it will produce the same effect in
SDL_Init for example.