os-solaris/7168: More detailed information relating to problem 7159

[Richard Meyer <rm...@befree.com>]

>Number:         7168
>Category:       os-solaris
>Synopsis:       More detailed information relating to problem 7159
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Wed Jan 31 10:40:02 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     rmeyer@befree.com
>Release:        1.3.12
>Organization:
apache
>Environment:
See PR# 7159, this is intended to provide more detailed information on the problem described there.
>Description:
Learning a bit more about gdb, I've attached to a hung process and entered gdb> info threads
(gdb) info threads
  8 Thread 3          0xef5b9790 in __lwp_sema_wait ()
  7 Thread 2 (LWP 2)  0xef5b98d8 in __signotifywait ()
  6 Thread 1 (LWP 1)  0xef5b8688 in _read ()
  5 LWP    6          0xef5b9744 in ___lwp_cond_wait ()
  4 LWP    6          0xef5b9744 in ___lwp_cond_wait ()
  3 LWP    4          0xef5b9790 in __lwp_sema_wait ()
  2 LWP    2          0xef5b98d8 in __signotifywait ()
* 1 LWP    1          0xef5b8688 in _read ()

Connecting to the unique threads and issueing >info stack calls I get :
(gdb) thread 1
[Switching to LWP    1        ]
#0  0xef5b8688 in _read ()
(gdb) info stack
#0  0xef5b8688 in _read ()
#1  0xef365b8c in _ti_read ()
#2  0x1fb58 in buff_read (fb=0xb1a48, buf=0xb1a88, nbyte=4096) at buff.c:299
#3  0x1fac8 in saferead_guts (fb=0xb1a48, buf=0xb1a88, nbyte=4096) at buff.c:662
#4  0x1db30 in read_with_errors (fb=0xb1a48, buf=0xb1a88, nbyte=4096) at buff.c:713
#5  0x1dffc in ap_bgets (buff=0xefffd800 "", n=8192, fb=0xb1a48) at buff.c:866
#6  0x340a0 in getline (s=0xefffd800 "", n=8192, in=0xb1a48, fold=0) at http_protocol.c:757
#7  0x34538 in read_request_line (r=0x644c68) at http_protocol.c:880
#8  0x34f18 in ap_read_request (conn=0x643c28) at http_protocol.c:1038
#9  0x308f8 in child_main (child_num_arg=3) at http_main.c:4166
#10 0x30ca4 in make_child (s=0xa3b78, slot=3, now=980869018) at http_main.c:4336
#11 0x30db4 in startup_children (number_to_start=2) at http_main.c:4363
#12 0x31694 in standalone_main (argc=1, argv=0xeffffbcc) at http_main.c:4651
#13 0x32240 in main (argc=1, argv=0xeffffbcc) at http_main.c:4978

(gdb) thread 2
[Switching to LWP    2        ]
#0  0xef5b98d8 in __signotifywait ()
(gdb) info stack
#0  0xef5b98d8 in __signotifywait ()
#1  0xef35bdec in _dynamiclwps ()

(gdb) thread 3
[Switching to LWP    4        ]
#0  0xef5b9790 in __lwp_sema_wait ()
(gdb) info stack
#0  0xef5b9790 in __lwp_sema_wait ()
#1  0xef357ea0 in _park ()
#2  0xef357b84 in _swtch ()
#3  0xef35b000 in _reap_wait ()
#4  0xef35ad8c in _reaper ()

These are in addition to the stack trace I provided for the _lwp_cond_wait thread yesterday.

BTW, we just heard from Sun and the bugfix which may address this problem won't be available publicly until March 9,2001.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <ap...@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]