Segmentation fault, Switching to Thread

Unga · September 19, 2011, 5:18pm

Hi all

This is FreeBSD 8.1 and SDL 1.3.

Quite often I get following error:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 296c66c0 (LWP 100131)]
0x28ee490e in _malloc_prefork () from /lib/libc.so.7
(gdb) where
#0 0x28ee490e in _malloc_prefork () from /lib/libc.so.7
#1 0x28ee616c in _malloc_thread_cleanup () from /lib/libc.so.7
#2 0x28da7348 in pthread_exit () from /lib/libthr.so.3
#3 0x28e5fc29 in RunThread (data=Could not find the frame base for “RunThread”.
) at src/thread/pthread/SDL_systhread.c:46
#4 0x28d9d75f in pthread_getprio () from /lib/libthr.so.3
#5 0x00000000 in ?? ()
(gdb) list
46 src/thread/pthread/SDL_systhread.c: No such file or directory.
in src/thread/pthread/SDL_systhread.c
(gdb)

Regards
Unga

icculus · September 19, 2011, 8:16pm

This is FreeBSD 8.1 and SDL 1.3.

Quite often I get following error:

Someone (either your app or SDL) is corrupting memory.

Do you use SDL_CreateThread() anywhere? If you don’t, it’s an SDL
bug…probably the audio thread.

–ryan.

Unga · September 20, 2011, 4:12am

This is FreeBSD 8.1 and SDL 1.3.

Quite often I get following error:

Someone (either your app or SDL) is corrupting memory.

Do you use SDL_CreateThread() anywhere? If you don’t, it’s
an SDL
bug…probably the audio thread.

–ryan.

Hi Ryan

Thanks for the reply.

In my app, I use SDL_CreateThread() for some threads.

In fact, I use pthread_create() also for some threads require run-time signalling.

And I have a block of code at the initialization, to do some checking, which assign a small work for each SDL thread (created by SDL_CreateThread()). These SDL threads are short lived, creates in probably hundreds in very quick succession without any delay in between.

Probably I can introduce a delay in creating those short lived SDL threads.

The said issue, does not happen every time but when it happens it happens quite early stage. I have not yet identified whether it is related to the short lived SDL threads.

Ideas to further dig the issue can surely be helpful.

Best regards
Unga— On Tue, 9/20/11, Ryan C. Gordon wrote:

From: Ryan C. Gordon
Subject: Re: [SDL] Segmentation fault, Switching to Thread
To: “SDL Development List”
Date: Tuesday, September 20, 2011, 4:16 AM

Brian_Barrett · September 20, 2011, 8:15am

Hi,

Why are you creating hundreds of short lived threads? Have you tried
commenting them out, and doing the work synchronously in the main()
thread? If this removes the problem, it is unlikely to be a SDL bug. I
doubt it is anyway, it sounds like a classic threading error.

Perhaps you have a race condition at work, where something is being
deallocated usually after, but occasionally before, your threads
complete. Are you passing complex state to these threads? Consider
commenting out the code that deallocates this state (or temporarily
heap-allocating it if it is currently automatically allocated). You
might be correct that the race condition is that your threads start
too soon (or perhaps in different orderings), before some critical
action is performed.

It might be interesting to try print the SDL thread identifiers and
times somewhere, as you start/stop them. I don’t know if SDL maintains
a mapping between OS thread identifiers and its own set, see if any
correspond to the thread identifier that GDB says it is switching to.

But ultimately, I really can’t imagine why you would need so many
threads, particularly short lived threads that run at start up. Sounds
like a great way to start slowly to me!

– BrianOn 20 September 2011 05:12, Unga wrote:

And I have a block of code at the initialization, to do some checking, which assign a small work for each SDL thread (created by SDL_CreateThread()). These SDL threads are short lived, creates in probably hundreds in very quick succession without any delay in between.

Probably I can introduce a delay in creating those short lived SDL threads.

icculus · September 20, 2011, 3:09pm

These SDL threads are short lived, creates in probably hundreds in very
quick succession without any delay in between.

I’m going to gamble that this is your bug.

If it’s not too much trouble to get it working on FreeBSD, you should
try running your app under Valgrind. It might hide a race condition, but
if you simply have a thread corrupting memory, it’ll likely show you
exactly where.

Failing that, you should try taking note of the thread id at creation time:

  SDL_Thread *thread = SDL_CreateThread(blah blah blah);
  /* This Uint32 is "SDL_threadID" in SDL 1.3 */
  Uint32 threadid = SDL_GetThreadID(thread);

When you crash in the debugger, the line “[Switching to Thread XXX (LWP
YYY)]” is printed out, and XXX should match the threadid of the crashing
thread.

–ryan.

Unga · September 20, 2011, 5:16pm

These SDL threads are short lived, creates in probably
hundreds in very
quick succession without any delay in between.

I’m going to gamble that this is your bug.?

If it’s not too much trouble to get it working on FreeBSD,
you should try running your app under Valgrind. It might
hide a race condition, but if you simply have a thread
corrupting memory, it’ll likely show you exactly where.

Failing that, you should try taking note of the thread id
at creation time:

? ???SDL_Thread thread =
SDL_CreateThread(blah blah blah);
? ???/ This Uint32 is "SDL_threadID"
in SDL 1.3 */
? ???Uint32 threadid =
SDL_GetThreadID(thread);

When you crash in the debugger, the line “[Switching to
Thread XXX (LWP YYY)]” is printed out, and XXX should match
the threadid of the crashing thread.

–ryan.

Hi Ryan

I think this information is good enough for me to locate where the problem is.

But next few days I have bit of traveling, as soon as I’m settle, I’ll dig to the bottom of this problem. Pls give me few days.

If anyone is interested to try the latest SDL 1.3 on FreeBSD, may use the attached patch.

Best regards
Unga
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL_1_3-FreeBSD8.patch
Type: application/octet-stream
Size: 1108 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110920/0f03e1e9/attachment.obj— On Tue, 9/20/11, Ryan C. Gordon wrote:

From: Ryan C. Gordon
Subject: Re: [SDL] Segmentation fault, Switching to Thread
To: “SDL Development List”
Date: Tuesday, September 20, 2011, 11:09 PM

Unga · September 20, 2011, 5:20pm

If anyone is interested to try the latest SDL 1.3 on
FreeBSD, may use the attached patch.

Sorry, forgot to include how to compile:

CPPFLAGS="-DNO_SDL_GLEXT"
./configure --prefix=/usr --sysconfdir=/etc

gmake >& sdl-make.log
gmake install >& sdl-install.log

Best regards
Unga— On Wed, 9/21/11, Unga <@Unga> wrote:

Unga · September 21, 2011, 6:08pm

These SDL threads are short lived, creates in probably
hundreds in very
quick succession without any delay in between.

I’m going to gamble that this is your bug.?

If it’s not too much trouble to get it working on FreeBSD,
you should try running your app under Valgrind. It might
hide a race condition, but if you simply have a thread
corrupting memory, it’ll likely show you exactly where.

Failing that, you should try taking note of the thread id
at creation time:

? ???SDL_Thread thread =
SDL_CreateThread(blah blah blah);
? ???/ This Uint32 is "SDL_threadID"
in SDL 1.3 */
? ???Uint32 threadid =
SDL_GetThreadID(thread);

When you crash in the debugger, the line “[Switching to
Thread XXX (LWP YYY)]” is printed out, and XXX should match
the threadid of the crashing thread.

–ryan.

I have identified the thread that crashes.

Lets use the following analogy:
Root thread->Main Contractor thread->Sub Contractor thread->worker threads

Worker threads are those short lived threads.

The Sub Contractor thread waits until all workers complete. Main Contractor waits until all Sub Contractor threads complete.

What crashes is the Main Contractor thread!

It crashes after it completes the job, and even after execute “return 0” to main thread.

And it hangs on its SDL_WaitThread().

Btw, I’m using today’s SDL 1.3.

Regards
Unga— On Tue, 9/20/11, Ryan C. Gordon wrote:

From: Ryan C. Gordon
Subject: Re: [SDL] Segmentation fault, Switching to Thread
To: “SDL Development List”
Date: Tuesday, September 20, 2011, 11:09 PM

icculus · September 21, 2011, 6:19pm

It crashes after it completes the job, and even after execute “return
0” to main thread.

This is because there’s a memory corruption, though (hence the crash in
the malloc subsystem from the original stacktrace).

Can you use valgrind on it?

–ryan.

Patrick_Baggett · September 21, 2011, 6:20pm

These SDL threads are short lived, creates in probably
hundreds in very
quick succession without any delay in between.

I’m going to gamble that this is your bug.

If it’s not too much trouble to get it working on FreeBSD,
you should try running your app under Valgrind. It might
hide a race condition, but if you simply have a thread
corrupting memory, it’ll likely show you exactly where.

Failing that, you should try taking note of the thread id
at creation time:
 SDL_Thread *thread =
SDL_CreateThread(blah blah blah);
/* This Uint32 is "SDL_threadID"
in SDL 1.3 */
Uint32 threadid =
SDL_GetThreadID(thread);

When you crash in the debugger, the line “[Switching to
Thread XXX (LWP YYY)]” is printed out, and XXX should match
the threadid of the crashing thread.

–ryan.
I have identified the thread that crashes.

Lets use the following analogy:
Root thread->Main Contractor thread->Sub Contractor thread->worker threads

Worker threads are those short lived threads.

The Sub Contractor thread waits until all workers complete. Main Contractor
waits until all Sub Contractor threads complete.

What crashes is the Main Contractor thread!

It crashes after it completes the job, and even after execute “return 0” to
main thread.

And it hangs on its SDL_WaitThread().

Btw, I’m using today’s SDL 1.3.

Regards
Unga

Unga,

Program structure aside, I’d love to look into this issue. What is needed
isn’t an analogy, it is a test case that demonstrates the crash. Try
demonstrating the problem in a single .c/.cpp file that everyone can test
and debug. Right now, I don’t think many people are convinced that is a bug
in SDL and not your code. Given that SDL gets a lot of testing on Linux, and
that FreeBSD also uses POSIX threads just like Linux, if there was a bug in
the threading API, it probably would have been found. That isn’t to say
there can’t be a bug, but that you need to try a bit harder to prove that
the issue exists. That compounded with the fact that you’re talking about
creating hundreds of threads makes people a little unsure about your code.

PatrickOn Wed, Sep 21, 2011 at 1:08 PM, Unga wrote:

— On Tue, 9/20/11, Ryan C. Gordon wrote:

From: Ryan C. Gordon
Subject: Re: [SDL] Segmentation fault, Switching to Thread
To: “SDL Development List”
Date: Tuesday, September 20, 2011, 11:09 PM

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

Unga · October 2, 2011, 3:18am

It crashes after it completes the job, and even after
execute “return
0” to main thread.

This is because there’s a memory corruption, though (hence
the crash in the malloc subsystem from the original
stacktrace).

Can you use valgrind on it?

–ryan.

Hi all

It was due to my programming error in my app where I double free, ie. used av_free() of ffmpeg twice in two different threads for the same memory portion to free. When the second av_free() executes it crashes.

Thanks for all who helped in this regard.

Best regards
Unga— On Thu, 9/22/11, Ryan C. Gordon wrote:

From: Ryan C. Gordon
Subject: Re: [SDL] Segmentation fault, Switching to Thread
To: “SDL Development List”
Date: Thursday, September 22, 2011, 2:19 AM