Segfault in libpthread / sem_wait

[ptitSeb]

During my many experiments, I get segfault. Some of them are releated to libpthread, always around the sem_wait function.

For example, while compiling libre office I get:


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x404066b0, pid=23440, tid=1078034432
#
# JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)
# Java VM: Java HotSpot(TM) Client VM (24.51-b03 mixed mode linux-arm )
# Problematic frame:
# C  [libpthread.so.0+0xd6b0]  sem_wait+0x14
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /media/sda1/sources/git/libo/workdir/CppunitTest/services.test.core/hs_err_pid23440.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

 

or while trying some mono game (FEZ here)

Program received signal SIGPWR, Power fail/restart.
[Switching to LWP 24427]
0x402c5788 in sem_wait () from /lib/libpthread-2.9.so
(gdb) bt
#0  0x402c5788 in sem_wait () from /lib/libpthread-2.9.so
#1  0x00261834 in mono_sem_wait (sem=sem@entry=0x354d7c <finalizer_sem>, alertable=alertable@entry=1) at mono-semaphore.c:101
#2  0x001c4d84 in finalizer_thread (unused=unused@entry=0x0) at gc.c:1077
#3  0x001a3d04 in start_wrapper_internal (data=<optimized out>) at threads.c:657
#4  start_wrapper (data=<optimized out>) at threads.c:704
#5  0x002674cc in inner_start_thread (arg=<optimized out>) at mono-threads-posix.c:84
#6  0x402be2f0 in ?? () from /lib/libpthread-2.9.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Any ideas where should I look to fix thoses Segfault?

 

[notaz]

Can you install glibc-dbg and see if it gives better stacktraces?
 

or while trying some mono game (FEZ here)


Program received signal SIGPWR, Power fail/restart.

Any ideas where should I look to fix thoses Segfault?

Hmm that's not even a segfault, never seen anything send SIGPWR..

 

[ptitSeb]

I'll do that.

And yeah, it's a strange signal...

 

[notaz]

Looking at the disassembly, at least in java's case it's NULL or invalid pointer being passed to sem_wait(). In this case even much newer x86 version of glibc crashes.

In mono's case, it looks like sem_wait is waiting for something as it's supposed to be, and then suddenly something else sends SIGPWR out of nowhere. You should probably put a breakpoint on raise() and see who is sending the signal.

 

[ptitSeb]

Hmmm, so the segfault in sem_wait is a side effect of something going wrong elsewhere. Difficult to track

 

[milkshake]

Oooh fez on pandora sounds good

 

[lunixbochs]

SIGPWR and SIGXCPU are probably used by the garbage collector. You might want to just set gdb to ignore them:

handle SIGPWR nostop noprint
handle SIGXCPU nostop noprint