Conference turris::digital_unix

8748.0. "signals mask modified when handling C++ exceptions" by TAEC::SANNA () Fri Feb 07 1997 04:55

Bonjour,


I have a problem with the signals mask. Somewhere in my code the signal mask is
modified when throwing (or catching) an exception : SIGPIPE is masked at the
start of the code; it is still masked just before throwing the exception; but it
is not masked any more in the catch of the exception.
This not occurs each time an exception is thrown and I don't understand what are
the circumstances that make this happens. Furthermore, the same test doesn't
always give the same result...


DecLadebug traces show that sigprocmask is called when an exception is thrown
(see traces below) but some tests have been done and it seems that this call
doesn't modify the mask.

My question is : Is it possible that the unwind to the catch handler is not
restoring the mask properly? Is there a known problem in this area?


Thanks and regards,

Isa.

$uname -a
OSF1 havane.vbo.dec.com V3.2 148 alpha


$what_is_installed CXX
CXXBASE540      installed       DEC C++ (cxx) for Digital UNIX
CXXLIB540       installed       DEC C++ static class libraries
CXXMAN540       installed       DEC C++ and class library manual pages
CXXSHRDA307     installed       DEC C++ Class Library, Run-Time Support
CXXV3HDR540     installed       DEC C++ header files for Digital UNIX V3.x
CXXV51CXX530    installed       DEC C++ V5.1 (v51cxx) for Digital UNIX
CXXV53CXX540    installed       DEC C++ Version 5.3 (v53cxx) for Digital UNIX



decladebug traces : this traces are relative to the throw of an exception.
Before this throw PIPE was in signals mask, in this exception catching PIPE
wasn't any more in the mask.

(ladebug) where
>0  0x3ff8051a708 in _sigprocmask(0x4a4d28, 0x3ffc01e3de0, 0x11fffe650, 0xacedba
de, 0x3ff00000003, 0x45586732) DebugInformationStrippedFromFile304
#1  0x3ff8051f3e8 in __sigsetjmp(0x3ffc19d9e50, 0x0, 0x0, 0x0, 0x0, 0x0) DebugIn
formationStrippedFromFile495
#2  0x3ff821db788 in signal_cxx_user_exception(0xffe0006, 0x0, 0x0, 0x0, 0x1, 0x
4a4808) /usr/proj/cxx1/cxxl_resd/aosf32_maint/src/cxx_exc.c:423
#3  0x3ff821db940 in __cxx_throw(0x3ffc1187e20, 0x11fffebb0, 0x3ff81d23d10, 0x3f
f81d23d78, 0x10, 0x11fffeba8) /usr/proj/cxx1/cxxl_resd/aosf32_maint/src/cxx_exc.
c:476
#4  0x3ff81d25d74 in _ThrowCVRException(cvrValue=52877530, routineName=0x4a3888=
"mcc_get_cvr_message", srcFile=0x3ff81cb9410="tfc_wp_trace.cxx", srcLine=356) tf
c_wp_exception.cxx:185
#5  0x3ff81d26ec4 in _ValidateFailed(cvrValue=52877530, msg=0x3ff81cb9428="mcc_g
et_cvr_message((MCC_T_Descriptor *)&cvrMsg, cvrValue)", srcFile=0x3ff81cb9410="t
fc_wp_trace.cxx", srcLine=356) tfc_wp_exception.cxx:349
#6  0x3ff81cdb574 in ((MCVR*)0x11fffef20)->GetMsg(cvrMsg={ ... }) tfc_wp_trace.c
xx:356
#7  0x3ff81cdb5b4 in ((MCVR*)0x11fffef20)->Dump(buffer={ ... }) tfc_wp_trace.cxx
:370
#8  0x3ff81cdb710 in ((MTraceItem*)0x4a5ce8)->Descriptor_dump(Buffer={ ... }, St
yle=1) tfc_wp_trace.cxx:420
#9  0x3ff81cdb9e0 in ((MTraceItem*)0x4a5ce8)->Dump(Buffer={ ... }, Style=1) tfc_
wp_trace.cxx:512
#10 0x3ff81cdbc84 in ((MTraceStream*)0x11fffef90)->Dump(i=7, Buffer=0x4a4e08, St
yle=1) tfc_wp_trace.cxx:666
#11 0x3ff81cdc128 in ((MTraceStream*)0x11fffef90)->operator const String() tfc_w
p_trace.cxx:736
#12 0x3ff81d25cec in _ThrowCVRException(cvrValue=1, routineName=0x0, srcFile=0x3
ff812507d0="gat_gat_lab_am.cxx", srcLine=127) tfc_wp_exception.cxx:182
#13 0x3ff812c0af4 in ((MModuleGAT_LAB_AM*)0x3ffc072e988)->OnPostProbe(context=0x
11ffff448) gat_gat_lab_am.cxx:127
#14 0x3ff81f1f614 in ((MModuleContext*)0x11ffff448)->ExecutePostProbe() tfc_fmk_
module.cxx:1217
#15 0x3ff81f1dde0 in ((MModule*)0x3ffc072e988)->Probe(applicationID=102) tfc_fmk
_module.cxx:445
#16 0x3ff812bfc5c in mcc_xmm_probe(applicationID=102) gat_gat_lab_am.cxx:86
#17 0x3ff820e1434 in mcc_call_probe_log(0x66, 0x3ff812bfbf0, 0x120018dd0, 0x1200
1acd0, 0x120018ec8, 0x3268009) DebugInformationStrippedFromFile109
#18 0x120018f50 in main(0x1000, 0x1e76, 0x120018978, 0x16f26, 0x100000000, 0x0)
DebugInformationStrippedFromFile2
(ladebug) c

    This is a known bug. Whether you can patch it yourself depends
    on how you have to link the C++ application. It used to be that
    the C++ rtl had its own copy of libexc.a -- if that's still true
    on V3.2C, you'll need a patched C++ library.
    
    Otherwise, you need to pick up this patched libexc.a and relink
    your application.
    
    PROBLEM:        (Case ID: EVT101544)            (Patch ID: OSF350-102)
    ********
    
    Programs linked with the libexc.a library can have their process signal
    masks corrupted while handling exceptions at runtime. Theproblem shows
    up when the process stops responding to signals. The ps -s command
    shows a mask of random signals blocked, including the one required to
    make the program function correctly.
    
    Ada and C++ programs seems to the most likely to experience the
    program.
    
    
    FILE(s):
    
    /usr/ccs/lib/cmplrs/cc/libexc.a         subset OSFCMPLRSEXT350
    CHECKSUM: 09358     23
    --------------------------------------------------------------
    
    INSTALLATION INSTRUCTIONS:
    
    Become superuser and execute the following commands:
    
    # cd /usr/ccs/lib/cmplrs/cc
    # cp /patches/libexc.a libexc.a.new
    # chown bin:bin libexc.a.new
    # chmod 644 libexc.a.new
    # ln libexc.a libexc.a.orig
    # mv libexc.a.new libexc.a
    
    
    And please don't ask me how to get the patch. The patch thing has
    been in such state lately, I have no idea.
    
    The problem here is a mismatch between the kernel's and the exc
    library's expectations about restoring the signal mask. The library
    never made a change is was supposed to for V3 and is passing
    a garbage signal mask in a sigreturn call when going a longjmp....
    
    
    
    

When using Unix 4.0B, do we have to use a similar patch or 
simply use /usr/shlib/libexc.so without problem ?

Thanks,
Laurent
[Posted by WWW Notes gateway]

    This has been fixed in the V4.0 stream since practically the
    first internal baselevel. Using the libexc.so or the .a for
    that matter on V4 fixes this problem. Of course, bringing a
    bad static binary from V3 to V4 will still fail....