[Libunwind-devel] Having problems with throw exception within signal handler

[Guy Charbonneau]

Hi Mailing list.  Copy already sent to Dave.

 

 

I have a large legacy code base running on two different platforms. X86 and PPC. Both are running Linux but one is centos 7.3 and the other is yocto / WRL. They running different gcc version:

X86/redhat 4.8.5

PPC/yocto 5.2.0

 

Both seem to be running libunwind 1.1

 

The app uses multi-threads where most threads run different entry points. ( i.e. not like a httpd where most threads run the same code. ).

This legacy app was created for robustness. As such when a thread receives a sigsegv or other async signal we want the rest of the app to continue running and only shutdown this offending thread. Our infrastructure has resource reclamation and semaphore / mutex cleanup.

 

The current way of dealing with this is in the thread creation we wrap the call to the entry point of the thread with a try catch block and in the signal handler we throw SegmentationFault().

Then deal with the cleanup outside the signal handler context but still in the thread that caused the problem. Being in the same thread it allows us to release mutex if they were taken where if we were in a different thread ( like a cleanup thread ) we could cause problems releasing a mutex.

 

For x86 gcc 4.8.5 this works fantastic.

 

On PPC I keep getting phase 1 error of _URC_FATAL_PHASE1_ERROR.

 

I tried to gdb step thru the code in libunwind to no avail given the complexity of personalities, cursors, … I’m not even sure how many levels of unwind it manages to get thru before error. Seems like 1 then error. I say “I think” due to optimization jumping around during gdb next. ( not in a signal handler context. Just some coded runtime catcher routine ).

 

 

 

 

 

Are you aware of any issues on ppc / yocto  / gcc 5.2.0 that might cause these issues?

 

Info and what I’ve tried/checked:

 

 

g++ cflags are as follows:

x86:

g++                                    -c -Wall -fshort-enums -pthread -fnon-call-exceptions                                                             -m32  -std=c++11 -Wall -g3 -O0

 

ppc:

powerpc-wrs-linux-g++ -c -Wall -fshort-enums -pthread -fnon-call-exceptions -DMOST_SIGNIFICANT_BIT_FIRST -m32 -                                               mhard-float -mcpu=603e --sysroot=/net/wrl/SDK/wrlinux-8.0.0.15/BSP_1.9.0/wrlinux-small/sysroots/ppc603e-wrs-Linux                                                                          -g3 -O0

 

 

I do call unwind for logs including traceback purpose and it does work great on both platforms.

 

 

As a side experiment I tried the try catch mechanism where the throw exception is in our runtime error catcher. It does not work there either.

 

 

 

P.S. WRL is short for Wind River Linux. Who we bought support for the yocto distro for ppc.

 

 

Gdb back trace for ppc on non-signal handler throw.

(gdb) bt

#0  _Unwind_RaiseException (address@hidden)

    at /usr/src/debug/libunwind/1.1-r0/libunwind-1.1/src/unwind/RaiseException.c:57

#1  0x0f8fa7bc in __cxxabiv1::__cxa_throw (obj=0x121bb360,

    tinfo=0x1156c348 <typeinfo for SegmentationFault>, dest=0x0)

    at /localhome/malikk/workspace/mitel_bsp_cx_dev_0018/bitbake_build/tmp/work-shared/gcc-5.2.0-r0/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc:82

#2  0x100938a8 in vkerror (fmt=0x1121f558 "%d not in [%d .. %d]\n",

    argp=0x7186c348)

    at /localhome/charbonn/snap/charb_ccJira1/vobs/cc/mainc/new_c/kernel/mckernel.cc:470

#3  0x100939a0 in Run_time_error (format=0x1121f558 "%d not in [%d .. %d]\n")

    at /localhome/charbonn/snap/charb_ccJira1/vobs/cc/mainc/new_c/kernel/mckernel.cc:491

#4  0x110d0d7c in Range_check(int, int, int) ()

#5  0x10b96238 in Range<unsigned short, 1, 5>::check_valid (this=0x7186c450,

    test_value=6)

    at /localhome/charbonn/snap/charb_ccJira1/vobs/cc/mainc/new_c/rtl/Range.h:30

#6  0x10b95f7c in Range<unsigned short, 1, 5>::operator= (this=0x7186c450,

    address@hidden: 6)

    at /localhome/charbonn/snap/charb_ccJira1/vobs/cc/mainc/new_c/rtl/Range.h:35

---Type <return> to continue, or q <return> to quit---

#7  0x10b92088 in version_entered (parameters=...)

    at /localhome/charbonn/snap/charb_ccJira1/vobs/cc/mainc/source/verscmd.cc:222

#8  0x10bd41e0 in call_application(action_data_S&, Array<Range<unsigned char, 0, 255>, 1, 160>&) ()

#9  0x10bd4728 in decode_command(bool) ()

#10 0x10bd4d04 in mtce_cmd(Sstring const&) ()

#11 0x10133a8c in program_maint_term() ()

#12 0x10091578 in thread_start (double_arg=0x71d01cb8)

    at /localhome/charbonn/snap/charb_ccJira1/vobs/cc/mainc/new_c/kernel/threads.cc:917

#13 0x0fb13eb0 in start_thread (arg=0x7186d140) at pthread_create.c:462

#14 0x0f6ad308 in clone ()

    at ../sysdeps/unix/sysv/linux/powerpc/powerpc32/clone.S:93

 

The catch should be in frame 12. Which is common to every thread.

 

---

NOTE: This e-mail (including any attachments) is for the sole use of the intended recipient(s) and may contain information that is confidential and/or protected by legal privilege. Any unauthorized review, use, copy, disclosure or distribution of this e-mail is strictly prohibited. If you are not the intended recipient, please notify Mitel immediately and destroy all copies of this e-mail. Mitel does not accept any liability for breach of security, error or virus that may result from the transmission of this message.