| Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
| Notice: | Welcome to the Digital UNIX Conference |
| Moderator: | SMURF::DENHAM |
| Created: | Thu Mar 16 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 10068 |
| Total number of notes: | 35879 |
I got the following problem report from a customer. Is there enough info
to assess whether this is a problem or not?:
---------------
I have a customer ( ESCA ) running on a 600 5/333 w/ 3.2E and objectstore.
They are experiencing problems with signal handling.
I have a particial stack trace below:
VVVVVV
>0 0x253d8cf8 in mem_signal_handler(sig=11, si=0x2, sc=0x11ffccf8)
cl_llpl.c
c:79
#1 0x25759418
#2 0x25153bcc in ((_Database_high*)0x3d5ac)->find_root(name_arg=0x24fa26d8="
__appl_schema") root.cc:87
It is normal for objectstore to take a fault in find_root.
The problem appears to be in frame 0 where si=0x2
I have been told that:
"The top frame shows a bogus value for si - this looks like the
problem with the DU 3.2x kernel wrt threads/signal handlers (they,
Digital, fixed it in DU 4.0). Anyone want to confirm this?
So can you confirm this?
Is there a patch for this for the 3.2e O/S?
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 9214.1 | SMURF::DENHAM | Digital UNIX Kernel | Tue Mar 18 1997 20:06 | 14 | |
I assume "si" is meant to mean and "siginfo_t *"?
Is so, such a pointer is supplied as the second argument to
signal handler only if SA_SIGINFO is set for, in this case,
SIGSEGV. Otherwise, you get an integer "code" as the second
argument a la 4.3BSD.
It's my code and all, but I can't think of anything that's
been fixed per se in V4.0. We did some dinking around
for UNIX 95 support, but I can't make a direct connection
there to what's being seen by the customer.
So, first let's confirm that they're setting SA_SIGINFO
and take it from there...
| |||||