Trouble with rendering operations in a timer

Hi :slight_smile:

I have an issue I can’t fix nor understand, in a code I did on 1.2, and adapt on 2.0. It’s a simple scolltext, called by a timer each 30ms.
On a very old single core machine, all works perfecly.
On every more modern machine, it crashes with a seg fault.

It appears that each time I do an operation on the renderer (SDL_RenderCopy, tried also with a single SDL_RenderClear) in the timer, I have a segfault. I don’t understand why it crashes ONLY in the timer, and ONLY on some machines.

Now for some code lines:

  • the timer:
    timer = SDL_AddTimer(30, doscrolltext, NULL); --> the timer calling the scrolling function (I do not need to pass arguments)

  • part of the scrolling function: (renderer = the renderer, scrolltextbuffert = the whole scrolltext bitmap texture, for the test : approx 1700*32 pixels)
    Uint32 doscrolltext(Uint32 intervalle, void *param)
    various SDL_Rect defs …
    SDL_RenderCopy (renderer, scrolltextbuffert, &src, &dst);
    SDL_RenderPresent(renderer);

    return(intervalle);

The scrolling function works nice on SDL 1.2, and under SDL 2.0 on the old machine, all works nice, too. Seems to crash on more modern dual core / integrated graphics card. Or, maybe I’m doing the wrong way with the timer.
I suspect some sort of lock on the renderer, and when the prog is in the timer, it tries to operate on the protected renderer memzone ? I really don’t understand why it works on the old machine, and not on others.
(I have to say, I’m quite new in C and SDL)

Your comments are welcome :slight_smile:
Thanks,
Nicolas

I am probably mistaken, since I last checked long ago, but the documentation warns that timers may run in separate threads. The Render API, however, clearly suggests that all rendering commands must happen in the main thread.

Cheers,
Aggelos KolaitisOn Aug 29, 2013, at 3:00 PM, “HM_Kaiser” wrote:

Hi

I have an issue I can’t fix nor understand, in a code I did on 1.2, and adapt on 2.0. It’s a simple scolltext, called by a timer each 30ms.
On a very old single core machine, all works perfecly.
On every more modern machine, it crashes with a seg fault.

It appears that each time I do an operation on the renderer (SDL_RenderCopy, tried also with a single SDL_RenderClear) in the timer, I have a segfault. I don’t understand why it crashes ONLY in the timer, and ONLY on some machines.

Now for some code lines:

  • the timer:
    timer = SDL_AddTimer(30, doscrolltext, NULL); --> the timer calling the scrolling function (I do not need to pass arguments)

  • part of the scrolling function: (renderer = the renderer, scrolltextbuffert = the whole scrolltext bitmap texture, for the test : approx 1700*32 pixels)
    Uint32 doscrolltext(Uint32 intervalle, void *param)
    various SDL_Rect defs …
    SDL_RenderCopy (renderer, scrolltextbuffert, &src, &dst);
    SDL_RenderPresent(renderer);

    return(intervalle);

The scrolling function works nice on SDL 1.2, and under SDL 2.0 on the old machine, all works nice, too. Seems to crash on more modern dual core / integrated graphics card. Or, maybe I’m doing the wrong way with the timer.
I suspect some sort of lock on the renderer, and when the prog is in the timer, it tries to operate on the protected renderer memzone ? I really don’t understand why it works on the old machine, and not on others.
(I have to say, I’m quite new in C and SDL)

Your comments are welcome
Thanks,
Nicolas


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

Use SDL_GetTicks() for interval-based actions (animations, physics, whatever). This is essentially how one would implement timers if they’re not system-provided anyway, with the upside that one doesn’t need to worry about issues resulting from the function being run on another thread (which are largely non-existent on uniprocessor systems).------------------------
Nate Fries

Thanks a lot !

… g++ -o my_project project.o … -lmingw32 -lSDL2main -lSDL2 -std=c++0x

I try to migrate one of my projects to SDl2. All files from my makefile compile
without errors, but the linker? tells me this afterwards:

d:/mingw/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-
mingw32/lib/…/lib/libSDL2main.a(SDL_windows_main.o): In function console_main' : /Users/slouken/release/SDL/SDL2-2.0.0-source/foo-x64/../src/main/windows/SDL_win dows_main.c:140: undefined reference toSDL_main’
collect2.exe: error: ld returned 1 exit status
makefile:4: recipe for target ‘mole’ failed
mingw32-make: *** [my_project] Error 1

The “slouken-path” should not be here, right? :slight_smile: Sam?

Other SDL2 “test-examples” , for example like this
(http://wiki.libsdl.org/SDL_CreateRenderer ) work fine!

What am I doing wrong?

Got it!
Seems like the argcs are necessary in the int main(…

int main( int argc, char* args[] )
{

This is weird anyway. :(>

… g++ -o my_project project.o … -lmingw32 -lSDL2main -lSDL2 -std=c++0x

I try to migrate one of my projects to SDl2. All files from my makefile
compile
without errors, but the linker? tells me this afterwards:

d:/mingw/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-
mingw32/lib/…/lib/libSDL2main.a(SDL_windows_main.o): In function
console_main' : /Users/slouken/release/SDL/SDL2-2.0.0-source/foo-x64/../src/main/windows/SDL_win dows_main.c:140: undefined reference toSDL_main’
collect2.exe: error: ld returned 1 exit status
makefile:4: recipe for target ‘mole’ failed
mingw32-make: *** [my_project] Error 1

The “slouken-path” should not be here, right? :slight_smile: Sam?

Other SDL2 “test-examples” , for example like this
(http://wiki.libsdl.org/SDL_CreateRenderer ) work fine!

What am I doing wrong?


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

Settling on a single function prototype is the only way to be able to
override main() reasonably easily :confused: (tripped over this before by
using const char** instead of char** for argv)

2013/8/30, Julian Winter :> Got it!

Seems like the argcs are necessary in the int main(…

int main( int argc, char* args[] )
{

This is weird anyway. :frowning:

… g++ -o my_project project.o … -lmingw32 -lSDL2main -lSDL2
-std=c++0x

I try to migrate one of my projects to SDl2. All files from my makefile
compile
without errors, but the linker? tells me this afterwards:

d:/mingw/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-
mingw32/lib/…/lib/libSDL2main.a(SDL_windows_main.o): In function
console_main' : /Users/slouken/release/SDL/SDL2-2.0.0-source/foo-x64/../src/main/windows/SDL_win dows_main.c:140: undefined reference toSDL_main’
collect2.exe: error: ld returned 1 exit status
makefile:4: recipe for target ‘mole’ failed
mingw32-make: *** [my_project] Error 1

The “slouken-path” should not be here, right? :slight_smile: Sam?

Other SDL2 “test-examples” , for example like this
(http://wiki.libsdl.org/SDL_CreateRenderer ) work fine!

What am I doing wrong?


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

you need to have SDL_main(int, char **) instead of main/WinMain/wmain/wWinMain.
Alternatively, you can just not link to libSDL2main, but you’ll need to define your own WinMain for release (console-less) builds.------------------------
Nate Fries

**
Got it!
Seems like the argcs are necessary in the int main(…

int main( int argc, char* args[] )
{

This is weird anyway. :frowning:

This is standard C fwiw…

VittorioOn Friday, August 30, 2013, Julian Winter wrote:

… g++ -o my_project project.o … -lmingw32 -lSDL2main -lSDL2
-std=c++0x

I try to migrate one of my projects to SDl2. All files from my makefile
compile
without errors, but the linker? tells me this afterwards:

d:/mingw/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-

mingw32/lib/…/lib/libSDL2main.a(SDL_windows_main.o): In function
`console_main’
:

/Users/slouken/release/SDL/SDL2-2.0.0-source/foo-x64/…/src/main/windows/SDL_win

dows_main.c:140: undefined reference to `SDL_main’
collect2.exe: error: ld returned 1 exit status
makefile:4: recipe for target ‘mole’ failed
mingw32-make: *** [my_project] Error 1

The “slouken-path” should not be here, right? :slight_smile: Sam?

Other SDL2 “test-examples” , for example like this
(http://wiki.libsdl.org/SDL_CreateRenderer ) work fine!

What am I doing wrong?


SDL mailing list
SDL at lists.libsdl.org <javascript:_e({}, ‘cvml’,
‘SDL at lists.libsdl.org’);>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

In C int main(void) is totally valid.On Tue, Oct 1, 2013 at 10:22 PM, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

On Friday, August 30, 2013, Julian Winter wrote:

Got it!
Seems like the argcs are necessary in the int main(…

int main( int argc, char* args[] )
{

This is weird anyway. :frowning:

This is standard C fwiw…

Vittorio

… g++ -o my_project project.o … -lmingw32 -lSDL2main -lSDL2
-std=c++0x

I try to migrate one of my projects to SDl2. All files from my makefile
compile
without errors, but the linker? tells me this afterwards:

d:/mingw/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-
mingw32/lib/…/lib/libSDL2main.a(SDL_windows_main.o): In function
`console_main’
:

/Users/slouken/release/SDL/SDL2-2.0.0-source/foo-x64/…/src/main/windows/SDL_win
dows_main.c:140: undefined reference to `SDL_main’
collect2.exe: error: ld returned 1 exit status
makefile:4: recipe for target ‘mole’ failed
mingw32-make: *** [my_project] Error 1

The “slouken-path” should not be here, right? :slight_smile: Sam?

Other SDL2 “test-examples” , for example like this
(http://wiki.libsdl.org/SDL_CreateRenderer ) work fine!

What am I doing wrong?


SDL mailing list
SDL at lists.libsdl.org
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

I know, it is just non-weird :slight_smile:
VittorioOn Wednesday, October 2, 2013, Andre D wrote:

In C int main(void) is totally valid.

On Tue, Oct 1, 2013 at 10:22 PM, Vittorio Giovara <@Vittorio_Giovara <javascript:;>> wrote:

On Friday, August 30, 2013, Julian Winter wrote:

Got it!
Seems like the argcs are necessary in the int main(…

int main( int argc, char* args[] )
{

This is weird anyway. :frowning:

This is standard C fwiw…

Vittorio

… g++ -o my_project project.o … -lmingw32 -lSDL2main -lSDL2
-std=c++0x

I try to migrate one of my projects to SDl2. All files from my
makefile

compile
without errors, but the linker? tells me this afterwards:

d:/mingw/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/4.8.1/…/…/…/…/x86_64-w64-

mingw32/lib/…/lib/libSDL2main.a(SDL_windows_main.o): In function
`console_main’
:

/Users/slouken/release/SDL/SDL2-2.0.0-source/foo-x64/…/src/main/windows/SDL_win

dows_main.c:140: undefined reference to `SDL_main’
collect2.exe: error: ld returned 1 exit status
makefile:4: recipe for target ‘mole’ failed
mingw32-make: *** [my_project] Error 1

The “slouken-path” should not be here, right? :slight_smile: Sam?

Other SDL2 “test-examples” , for example like this
(http://wiki.libsdl.org/SDL_CreateRenderer ) work fine!

What am I doing wrong?


SDL mailing list
SDL at lists.libsdl.org <javascript:;>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org <javascript:;>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org <javascript:;>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

In C even just main() (without any types) is valid.

This is really just a side-effect of main being remapped as a macro to
SDL_main which of course doesn’t have the flexibility of the real
main, so it’s stuck with a single possible prototype. This ended up
biting me because I was using const char **argv instead of char **argv
(despite the fact that ABI-wise they were identical).

In C even just main() (without any types) is valid.

“Is valid” no, “works” maybe, it’s quite compiler dependent.

This is really just a side-effect of main being remapped as a macro to
SDL_main which of course doesn’t have the flexibility of the real
main, so it’s stuck with a single possible prototype. This ended up
biting me because I was using const char **argv instead of char **argv
(despite the fact that ABI-wise they were identical).

Surprisingly I’ve seen this breakage many times on windows/mingw, but
rarely on unix.

VittorioOn Wed, Oct 2, 2013 at 7:57 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

“Is valid” no, “works” maybe, it’s quite compiler dependent.

Incorrect: int main(void) is in C90 and C99 spec even.On Wed, Oct 2, 2013 at 3:52 AM, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

On Wed, Oct 2, 2013 at 7:57 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

In C even just main() (without any types) is valid.

“Is valid” no, “works” maybe, it’s quite compiler dependent.

This is really just a side-effect of main being remapped as a macro to
SDL_main which of course doesn’t have the flexibility of the real
main, so it’s stuck with a single possible prototype. This ended up
biting me because I was using const char **argv instead of char **argv
(despite the fact that ABI-wise they were identical).

Surprisingly I’ve seen this breakage many times on windows/mingw, but
rarely on unix.

Vittorio


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

From the spec:

5.1.2.2.1 Program startup
The function called at program startup is named main. The
implementation declares no
prototype for this function. It shall be defined with a return type of
int and with no
parameters:
int main(void) { /* … */ }
or with two parameters (referred to here as argc and argv, though any
names may be
used, as they are local to the function in which they are declared):
int main(int argc, char argv[]) { / … */ }
or equivalent;9) or in some other implementation-defined manner.On Wed, Oct 2, 2013 at 3:55 AM, Andre D <@Andre_D> wrote:

“Is valid” no, “works” maybe, it’s quite compiler dependent.

Incorrect: int main(void) is in C90 and C99 spec even.

On Wed, Oct 2, 2013 at 3:52 AM, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

On Wed, Oct 2, 2013 at 7:57 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

In C even just main() (without any types) is valid.

“Is valid” no, “works” maybe, it’s quite compiler dependent.

This is really just a side-effect of main being remapped as a macro to
SDL_main which of course doesn’t have the flexibility of the real
main, so it’s stuck with a single possible prototype. This ended up
biting me because I was using const char **argv instead of char **argv
(despite the fact that ABI-wise they were identical).

Surprisingly I’ve seen this breakage many times on windows/mingw, but
rarely on unix.

Vittorio


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

From the spec:

5.1.2.2.1 Program startup
The function called at program startup is named main. The
implementation declares no
prototype for this function. It shall be defined with a return type of
int and with no
parameters:
int main(void) { /* … */ }
or with two parameters (referred to here as argc and argv, though any
names may be
used, as they are local to the function in which they are declared):
int main(int argc, char argv[]) { / … */ }
or equivalent;9) or in some other implementation-defined manner.

“Is valid” no, “works” maybe, it’s quite compiler dependent.

Incorrect: int main(void) is in C90 and C99 spec even.

Umh that’s what I said, “int main(void)” is fine, “main()” is not, AFAIK.

VittorioOn Wed, Oct 2, 2013 at 9:57 AM, Andre D wrote:

On Wed, Oct 2, 2013 at 3:55 AM, Andre D wrote:

On Wed, Oct 2, 2013 at 3:52 AM, Vittorio Giovara <@Vittorio_Giovara> wrote:

On Wed, Oct 2, 2013 at 7:57 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

In C even just main() (without any types) is valid.

“Is valid” no, “works” maybe, it’s quite compiler dependent.

This is really just a side-effect of main being remapped as a macro to
SDL_main which of course doesn’t have the flexibility of the real
main, so it’s stuck with a single possible prototype. This ended up
biting me because I was using const char **argv instead of char **argv
(despite the fact that ABI-wise they were identical).

Surprisingly I’ve seen this breakage many times on windows/mingw, but
rarely on unix.

Vittorio


SDL mailing list
SDL at lists.libsdl.org
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

Ah, I understand now, yes, implicit int return type is historically
wonky. If main() works it is not defining a void return type, it is
defining an implicit int return type and might not work everywhere
following modern standards (I think -Wreturn-type warns).On Wed, Oct 2, 2013 at 4:02 AM, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

On Wed, Oct 2, 2013 at 9:57 AM, Andre D <@Andre_D> wrote:

From the spec:

5.1.2.2.1 Program startup
The function called at program startup is named main. The
implementation declares no
prototype for this function. It shall be defined with a return type of
int and with no
parameters:
int main(void) { /* … */ }
or with two parameters (referred to here as argc and argv, though any
names may be
used, as they are local to the function in which they are declared):
int main(int argc, char argv[]) { / … */ }
or equivalent;9) or in some other implementation-defined manner.

On Wed, Oct 2, 2013 at 3:55 AM, Andre D <@Andre_D> wrote:

“Is valid” no, “works” maybe, it’s quite compiler dependent.

Incorrect: int main(void) is in C90 and C99 spec even.

Umh that’s what I said, “int main(void)” is fine, “main()” is not, AFAIK.

Vittorio

On Wed, Oct 2, 2013 at 3:52 AM, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

On Wed, Oct 2, 2013 at 7:57 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

In C even just main() (without any types) is valid.

“Is valid” no, “works” maybe, it’s quite compiler dependent.

This is really just a side-effect of main being remapped as a macro to
SDL_main which of course doesn’t have the flexibility of the real
main, so it’s stuck with a single possible prototype. This ended up
biting me because I was using const char **argv instead of char **argv
(despite the fact that ABI-wise they were identical).

Surprisingly I’ve seen this breakage many times on windows/mingw, but
rarely on unix.

Vittorio


SDL mailing list
SDL at lists.libsdl.org
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


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

I may be wrong on this, but I believe ansi C has implicit int, C99 does not.On Wed, Oct 2, 2013 at 4:05 AM, Andre D <@Andre_D> wrote:

Ah, I understand now, yes, implicit int return type is historically
wonky. If main() works it is not defining a void return type, it is
defining an implicit int return type and might not work everywhere
following modern standards (I think -Wreturn-type warns).

On Wed, Oct 2, 2013 at 4:02 AM, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

On Wed, Oct 2, 2013 at 9:57 AM, Andre D <@Andre_D> wrote:

From the spec:

5.1.2.2.1 Program startup
The function called at program startup is named main. The
implementation declares no
prototype for this function. It shall be defined with a return type of
int and with no
parameters:
int main(void) { /* … */ }
or with two parameters (referred to here as argc and argv, though any
names may be
used, as they are local to the function in which they are declared):
int main(int argc, char argv[]) { / … */ }
or equivalent;9) or in some other implementation-defined manner.

On Wed, Oct 2, 2013 at 3:55 AM, Andre D <@Andre_D> wrote:

“Is valid” no, “works” maybe, it’s quite compiler dependent.

Incorrect: int main(void) is in C90 and C99 spec even.

Umh that’s what I said, “int main(void)” is fine, “main()” is not, AFAIK.

Vittorio

On Wed, Oct 2, 2013 at 3:52 AM, Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

On Wed, Oct 2, 2013 at 7:57 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

In C even just main() (without any types) is valid.

“Is valid” no, “works” maybe, it’s quite compiler dependent.

This is really just a side-effect of main being remapped as a macro to
SDL_main which of course doesn’t have the flexibility of the real
main, so it’s stuck with a single possible prototype. This ended up
biting me because I was using const char **argv instead of char **argv
(despite the fact that ABI-wise they were identical).

Surprisingly I’ve seen this breakage many times on windows/mingw, but
rarely on unix.

Vittorio


SDL mailing list
SDL at lists.libsdl.org
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


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