[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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 |
8589.0. "sendsig: can't grow stack?" by CHEFS::DAVIDSONS () Sun Jan 26 1997 04:13
When a single threaded C++ program is linked -threads (required by a
library it uses) the following happens:
- parent (4419) forks child (4831)
- child immediatly calls gethostbyname(3), never returns!
- child receives signal 11 (segmentation violation) repeatedly
- child grows to ~33MB RSS
- child terminates because it can't grow stack
Any ideas how to debug/solve this?
Thanks,
Stuart.
(environment: DU 3.2D-1, C++ 5.1, lazy swap, 96MB RAM, 192MB swap 25% used)
*** increase limits in parent shell
limit -h datasize unlimited
limit -h stacksize unlimited
limit -h memoryuse unlimited
limit -h addressspace unlimited
limit datasize unlimited
limit stacksize unlimited
limit memoryuse unlimited
limit addressspace unlimited
*** confirm limits increased in parent process
(dbx) set $pid=4419
(dbx) px thread.stack.uthread.utask.uu_rlimit[2].rlim_max
0x7fffffffffffffff
(dbx) px thread.stack.uthread.utask.uu_rlimit[2].rlim_cur
0x40000000
(dbx) px thread.stack.uthread.utask.uu_rlimit[3].rlim_max
0x7fffffffffffffff
(dbx) px thread.stack.uthread.utask.uu_rlimit[3].rlim_cur
0x2000000
(dbx) px thread.stack.uthread.utask.uu_rlimit[7].rlim_max
0x4000000000
(dbx) px thread.stack.uthread.utask.uu_rlimit[7].rlim_cur
0x4000000000
(dbx) px vm_tune.vt_maxvas
0x4000000000
# ps -o sig,sigmask,sigcatch,wchan -p 4419
PENDING BLOCKED CAUGHT WCHAN
0 0 efa socket
# ps -o sig,sigmask,sigcatch,wchan -p 4831
PENDING BLOCKED CAUGHT WCHAN
0 0 afa pg_wait
*** trace (freeware tool) o/p (last 2 lines repeated until child terminates)
Tracing process /proc/04831
[4831]: stat ("/etc/svc.conf", 0x3ffc0099478) = 0 [ , <8.3075.12323 -rwxr-xr-x
1
bin bin 2045 854114780,789580057,789580057> ]
[4831]: open ("/etc/hosts", O_RDONLY, 0666) = 12
[4831]: SIGNAL [11 SIGSEGV]
[4831]: sigprocmask (3, 0x0, 0x0) = 1024
[4831]: SIGNAL [11 SIGSEGV]
[4831]: sigprocmask (3, 0x0, 0x0) = 1024
*** (the param's to sigprocmask from within gethostbyname doen't look valid)
*** child terminates
sendsig: can't grow stack, pid 4831, proc cm6.playback.nss, sig 11, pc
0x3ff8056
fefc
T.R | Title | User | Personal Name | Date | Lines |
---|
8589.1 | | COL01::LINNARTZ | | Mon Jan 27 1997 06:23 | 4 |
| you should apply patch OSFXXX-00106.
This should solve your problem
Pit
|
8589.2 | where's the patch? | CHEFS::DAVIDSONS | | Mon Jan 27 1997 13:07 | 7 |
| I checked guru::patches/osf/v3.2de1/README but could not find
patch 00106.
Can you give me a pointer?
Thanks,
Stuart.
|
8589.3 | | SMURF::MENNER | it's just a box of Pax.. | Mon Jan 27 1997 13:20 | 1 |
| "patch 106" is for the V4.0* stream.
|
8589.4 | Possible conflict? How's it built? | WTFN::SCALES | Despair is appropriate and inevitable. | Tue Jan 28 1997 13:47 | 9 |
| It's possible that your "single-threaded" application is running into conflict
with threads from some library that you're using.
.0> When a single threaded C++ program is linked -threads
Could you post the exact compile and link command(s)?
Webb
|
8589.5 | single thread | CHEFS::DAVIDSONS | | Tue Jan 28 1997 14:03 | 4 |
| OK, I'll post the compile & link commands but 'ps -m' shows only
one thread.
Stuart.
|
8589.6 | No threads no conflict.... | WTFN::SCALES | Despair is appropriate and inevitable. | Tue Jan 28 1997 14:48 | 9 |
| .5> only one thread.
Oh. Nevermind, then.
If the argument that you're passing to gethostbyname(3) looks OK, then I'd
suspect it was QAR time (or something similar).
Webb
|
8589.7 | Thanks, I'll QAR it. | CHEFS::DAVIDSONS | | Wed Jan 29 1997 13:26 | 1 |
|
|
8589.8 | recursive SEGV? | CHEFS::DAVIDSONS | | Wed Jan 29 1997 13:35 | 8 |
| What's the 'recursive SEGV problem' mentioned in note 8587?
(looks like my problem)
How does this happen?
How can I debug it?
Thanks,
Stuart.
|
8589.9 | Stating the obvious? | WTFN::SCALES | Despair is appropriate and inevitable. | Wed Jan 29 1997 18:29 | 18 |
| .8> What's the 'recursive SEGV problem' mentioned in note 8587?
A recursive SEGV results when the attempt to handle a SEGV results in another
SEGV.
.8> How does this happen?
Generally, it's the result of a bug in a signal handler routine. It can also
result if data on which a signal handler routine depends becomes corrupted.
.8> How can I debug it?
Running the program under a debugger (such as Ladebug) is usually a good
technique. The debugger can stop the program when the first SEGV occurs, which
may give you a good idea of what's going on...
Webb
|