Bug 48030 - Segmentation Fault
Summary: Segmentation Fault
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.2.14
Hardware: Sun Solaris
: P1 critical (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-20 14:26 UTC by Nick
Modified: 2012-01-23 19:17 UTC (History)
1 user (show)



Attachments
test fix for bug 48030 (1.08 KB, text/plain)
2009-10-20 18:49 UTC, Jeff Trawick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick 2009-10-20 14:26:43 UTC
Some child processes of httpd are segfaulting. 
gdb output from core dump file:

...
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal 11, Segmentation fault.
[New process 1837379    ]
[New process 67907    ]
[New process 198979    ]
[New process 264515    ]
[New process 330051    ]
[New process 395587    ]
[New process 461123    ]
[New process 526659    ]
[New process 592195    ]
[New process 657731    ]
[New process 723267    ]
[New process 788803    ]
[New process 854339    ]
[New process 919875    ]
[New process 985411    ]
[New process 1050947    ]
[New process 1116483    ]
[New process 1182019    ]
[New process 1247555    ]
[New process 1313091    ]
[New process 1378627    ]
[New process 1444163    ]
[New process 1509699    ]
[New process 1575235    ]
[New process 1640771    ]
[New process 1706307    ]
[New process 1771843    ]
#0  0xff21ae08 in apr_pollset_poll (pollset=0xdb1e8, timeout=-1, num=0x0, descriptors=0xfcbfbef8)
    at poll/unix/port.c:380
380                 pollset->result_set[i] =
(gdb) list
375         if (nget) {
376
377             pollset_lock_rings();
378
379             for (i = 0; i < nget; i++) {
380                 pollset->result_set[i] =
381                     (((pfd_elem_t*)(pollset->port_set[i].portev_user))->pfd);
382                 pollset->result_set[i].rtnevents =
383                     get_revent(pollset->port_set[i].portev_events);
384
(gdb) bt
#0  0xff21ae08 in apr_pollset_poll (pollset=0xdb1e8, timeout=-1, num=0x0, descriptors=0xfcbfbef8)
    at poll/unix/port.c:380
#1  0x0004d074 in listener_thread (thd=0x133e38, dummy=0xa0) at worker.c:687
#2  0xff21ecf0 in dummy_worker (opaque=0x133e38) at threadproc/unix/thread.c:142
#3  0xfefc8970 in _lwp_start () from /lib/libc.so.1
#4  0xfefc8970 in _lwp_start () from /lib/libc.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) print (((pfd_elem_t*)(pollset->port_set[i].portev_user))->pfd)
Cannot access memory at address 0x8
(gdb) print pollset->port_set
$2 = (port_event_t *) 0xdb228
(gdb) print pollset->port_set[i]
$4 = {portev_events = 0, portev_source = 0, portev_pad = 0, portev_object = 0, portev_user = 0x0}
Comment 1 Jeff Trawick 2009-10-20 14:36:52 UTC
Can you confirm that this occurs after a signal is received (such as when shutting down httpd), and before the affected process has handled any connections)?

(A parameter is updated by the kernel to indicate that an event is available; the crash occurs because the event user data is NULL (i.e., no event really was returned).)

I've seen that and have experimented with a fix, but have hoped (in vain so far) to get the attention of some body from that Solaris kernel area to explain.
Comment 2 Nick 2009-10-20 14:44:41 UTC
This always occurs shortly after httpd starts up and before any connections are made. Here is the output from error_log if it helps:

[Tue Oct 20 13:07:24 2009] [notice] Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.7d mod_jk/1.2.27 config
ured -- resuming normal operations
[Tue Oct 20 13:07:37 2009] [notice] child pid 2360 exit signal Segmentation fault (11), possible coredump i
n /usr/local/apache2
[Tue Oct 20 13:07:39 2009] [notice] child pid 2362 exit signal Segmentation fault (11), possible coredump i
n /usr/local/apache2
[Tue Oct 20 13:07:43 2009] [notice] child pid 2369 exit signal Segmentation fault (11), possible coredump i
n /usr/local/apache2
[Tue Oct 20 13:07:48 2009] [notice] child pid 2378 exit signal Segmentation fault (11), possible coredump i
n /usr/local/apache2
[Tue Oct 20 13:07:49 2009] [notice] child pid 2371 exit signal Segmentation fault (11), possible coredump i
n /usr/local/apache2
[Tue Oct 20 13:08:04 2009] [warn] child process 2395 still did not exit, sending a SIGTERM
[Tue Oct 20 13:08:05 2009] [notice] caught SIGTERM, shutting down
Comment 3 Jeff Trawick 2009-10-20 18:49:40 UTC
Created attachment 24403 [details]
test fix for bug 48030

zero out nget when kernel returns with nget set but no event has been filled in
Comment 4 Jeff Trawick 2009-10-20 18:51:17 UTC
Please try the test fix attached to this problem report.

cd httpd-2.2.14/srclib/apr
patch -p0 < /path/to/patchfile
make && make install
Comment 5 Nick 2009-10-21 08:15:42 UTC
I applied your patch and it seems to correct the issue. Processes are no longer segfaulting and no errors printed to error_log. Thank you very much for you quick response and assistance.
Comment 6 Nick 2009-10-21 08:16:16 UTC
I applied your patch and it seems to correct the issue. Processes are no longer segfaulting and no errors printed to error_log. Thank you very much for your quick response and assistance.
Comment 7 Bernd Leibing 2009-10-23 04:02:20 UTC
I have the same problem, but the test fix
doesn't help. All child processes are segfaulting after httpd starts up.
This only occurs on the heavy loaded production server. An identical server 
without http requests works without problems

[Thu Oct 22 18:40:43 2009] [info] mod_ssl/2.2.14 compiled against Server: Apache/2.2.14, Library: OpenSSL/0.9.8k
[Thu Oct 22 18:40:43 2009] [notice] Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8k mod_qos/8.18 PHP/5.2.11 configured -- resuming normal operations
[Thu Oct 22 18:40:43 2009] [info] Server built: Oct 22 2009 18:05:11
[Thu Oct 22 18:40:43 2009] [notice] child pid 7306 exit signal Segmentation fault (11)
[Thu Oct 22 18:40:43 2009] [notice] child pid 7307 exit signal Segmentation fault (11)
[Thu Oct 22 18:40:44 2009] [notice] child pid 7340 exit signal Segmentation fault (11)
[Thu Oct 22 18:40:44 2009] [notice] child pid 7343 exit signal Segmentation fault (11)
[Thu Oct 22 18:40:44 2009] [notice] child pid 7344 exit signal Segmentation fault (11)
[Thu Oct 22 18:40:44 2009] [notice] child pid 7345 exit signal Segmentation fault (11)
[Thu Oct 22 18:40:44 2009] [notice] child pid 7341 exit signal Segmentation fault (11)
Comment 8 Jeff Trawick 2009-10-23 04:18:56 UTC
Bernd:
Which MPM (prefork, worker, event)?
Can you get a coredump and backtrace for one of the crashes?
Comment 9 Bernd Leibing 2009-10-23 04:42:16 UTC
With a simple stresstest I managed to trigger  
th bug on an  otherwise unloaded server

I used:

ab -n 100 -c 20 http://myserver


Servertype: prefork MPM 

# dbx /www/apache/bin/httpd core.httpd.122.17147 
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc
Reading httpd
core file header read successfully
Reading ld.so.1
Reading libz.so.1
Reading libssl.so.0.9.8
Reading libcrypto.so.0.9.8
Reading libdl.so.1
Reading libm.so.2
Reading libaprutil-1.so.0.3.9
Reading libexpat.so.0.1.0
Reading libapr-1.so.0.3.9
Reading libuuid.so.1
Reading libsendfile.so.1
Reading librt.so.1
Reading libsocket.so.1
Reading libnsl.so.1
Reading libpthread.so.1
Reading libc.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libresolv.so.2
Reading libgen.so.1
Reading libcmd.so.1
Reading libscf.so.1
Reading libdoor.so.1
Reading libuutil.so.1
Reading libmp.so.2
Reading libphp5.so
Reading libpq.so.5.1
Reading libmysqlclient.so.15.0.0
Reading libldap-2.4.so.2.4.2
Reading liblber-2.4.so.2.4.2
Reading libfreetype.so.6
Reading libX11.so.4
Reading libXpm.so.4
Reading libpng12.so.0.18.0
Reading libjpeg.so.62.0.0
Reading libkstat.so.1
Reading libsched.so.1
Reading libclntsh.so.10.1
dbx: internal warning: "(null)"::srcname(InfoOrigin_CMDLINE): value "ntcontab.c" being set to "nt.c"
Reading libxml2.so.2.7.3
Reading libgcc_s.so.1
Reading libthread.so.1
Reading libsasl.so.1
Reading libgss.so.1
Reading libnnz10.so
Reading eaccelerator.so
t@1 (l@1) program terminated by signal SEGV (Segmentation Fault)
Current function is child_main
  635                   lr = pdesc[last_poll_idx++].client_data;
(dbx) where                                                                  
current thread: t@1
=>[1] child_main(child_num_arg = 1), line 635 in "prefork.c"
  [2] make_child(s = 0x8169fe0, slot = 1), line 758 in "prefork.c"
  [3] startup_children(number_to_start = 39), line 776 in "prefork.c"
  [4] ap_mpm_run(_pconf = 0x8162928, plog = 0x81a6a38, s = 0x8169fe0), line 997 in "prefork.c"
  [5] main(argc = 3, argv = 0x8047d40), line 740 in "main.c"
(dbx)
Comment 10 Jeff Trawick 2009-10-23 05:56:15 UTC
Thanks.  Were you running with the PR 48030 patch at the time of the crash?

Please load the core into dbx again and post the output from the following commands:

(dbx) dump
(dbx) p *pollset
(dbx) p pollset->port_set[0]
(dbx) p pollset->port_set[1]
(dbx) p pollset->port_set[2]
(dbx) p pollset->port_set[3]
(dbx) p pollset->port_set[4]
(dbx) p pdesc[0]
(dbx) p pdesc[1]
(dbx) p pdesc[2]
(dbx) p pdesc[3]
(dbx) p pdesc[4]

Thanks!
Comment 11 Bernd Leibing 2009-10-23 12:47:32 UTC
Yes I were running the PR 48030 patch.

dbx doesn't recognize a "p" command
(dbx) p *pollset
p: not found

I used the "print" command instead. Ok?
(dbx) dump          
pdesc = (nil)
numdesc = 0
csd = 0x2
current_conn = 0x2
ptrans = 0x8440178
pollset = 0x843e208
sbh = 0x843e200
child_num_arg = 1
last_poll_idx = 0
status = 0
allocator = 0x843e0e8
i = -1
bucket_alloc = 0x8444188
lr = (nil)
(dbx) print *pollset
*pollset = {
    pool       = 0x843e170
    nalloc     = 2U
    port_fd    = 9
    port_set   = 0x843e248
    result_set = 0x843e278
    flags      = 0
    ring_lock  = (nil)
    query_ring = {
        next = 0x843e2a0
        prev = 0x843e2c0
    }
    add_ring   = {
        next = 0x843e22c
        prev = 0x843e22c
    }
    free_ring  = {
        next = 0x843e234
        prev = 0x843e234
    }
    dead_ring  = {
        next = 0x843e23c
        prev = 0x843e23c
    }
    waiting    = 0
}
(dbx) print  pollset->port_set[0]
pollset->port_set[0] = {
    portev_events = 1
    portev_source = 4U
    portev_pad    = 4222U
    portev_object = 3U
    portev_user   = 0x843e2c0
}
(dbx) print  pollset->port_set[1]
pollset->port_set[1] = {
    portev_events = 0
    portev_source = 0
    portev_pad    = 0
    portev_object = 0
    portev_user   = (nil)
}
(dbx) print  pollset->port_set[2]
pollset->port_set[2] = {
    portev_events = 138666480
    portev_source = 57864U
    portev_pad    = 2115U
    portev_object = 4274616192U
    portev_user   = 0x8071370
}
(dbx) print  pollset->port_set[3]
pollset->port_set[3] = {
    portev_events = 0
    portev_source = 0
    portev_pad    = 0
    portev_object = 0
    portev_user   = (nil)
}
(dbx) print  pollset->port_set[4]
pollset->port_set[4] = {
    portev_events = 0
    portev_source = 0
    portev_pad    = 0
    portev_object = 0
    portev_user   = (nil)
}
(dbx) print  pdesc[0]           
dbx: reference through nil pointer
(dbx) print  pdesc[1]
dbx: cannot access address 0x14
(dbx) print  pdesc[2]
dbx: cannot access address 0x28
(dbx) print  pdesc[3]
dbx: cannot access address 0x3c
(dbx) print  pdesc[4]
dbx: cannot access address 0x50
(dbx)
Comment 12 Ruediger Pluem 2009-10-23 13:03:14 UTC
This is bad: status and numdesc are both 0. What is apr_pollset_poll (or better port in this case) want to tell us by this? There is an (no) event?
Or should we just do the same in this case as with APR_STATUS_IS_TIMEUP(status) and APR_STATUS_IS_EINTR(status)?
Comment 13 Jeff Trawick 2009-10-23 13:12:00 UTC
>Should we just do the same in this case as with APR_STATUS_IS_TIMEUP(status)
and APR_STATUS_IS_EINTR(status)?

uh, we better fix apr_pollset_poll()...

Meanwhile, at about the time Bernd was updating this PR I started to see some of the nonsensical behavior.

I think the patch attached to this PR is one necessary fix, and this issue of rv==0/pdesc==NULL is a different issue.  Hopefully I'll have a better update in the next few hours.
Comment 14 Jeff Trawick 2009-10-23 14:40:19 UTC
This is one of the more craptastic things I've seen in a while :(

S10 U5, Sun Studio 12, x86 (running in VMWare Fusion, though I doubt that has anything to do with it)

port_getn() returns -18857291
(so says fprintf; if I dbx it or truss it then port_getn() returns normal values)

APR 1.3.8 and previous: 

They checked for rc == -1 to catch errors.  Unless you ran it under truss or dbx, that logic didn't run.  (I wondered why there was the special case "else if (nget == 0) { rv = APR_TIMEUP; }").

APR 1.3.9:

This checks for rc < 0 to catch errors.  Apparently that logic catches things that aren't errors, and unless errno happens to be one of a couple of magic values real events won't be seen, and then the proper event won't ever be associated again.

--

I wonder if I could have a compiler bug that somehow is worked around when running under dbx or truss?  dbx I could believe, but I don't know about truss.  I need to play outside of APR, and also try other service levels of S10.
Comment 15 Jeff Trawick 2009-10-23 14:48:31 UTC
Bernd and Nick, could you please update the PR with your Solaris 10 update levels?
Comment 16 Bernd Leibing 2009-10-24 03:44:09 UTC
We use Solaris 10 10/08
Upgrade to the newest patchlevel is doable
if necessary.
Comment 17 Jeff Trawick 2009-10-24 04:39:01 UTC
Hi Bernd,

We'll track your problem with bug 48029.
Comment 18 Nick 2009-11-02 13:47:36 UTC
(In reply to comment #15)
> Bernd and Nick, could you please update the PR with your Solaris 10 update
> levels?

SunOS 5.10 Generic_141414-10 sun4v sparc
Comment 19 Markus Schiegl 2009-11-06 02:37:47 UTC
I have/had the same issues. HTTPD 2.2.14 immediately cored on startup (2.2.13 didn't)

...
[Fri Nov 06 07:05:06 2009] [notice] child pid 27488 exit signal Segmentation fault (11), possible coredump in /c/apache/versions/2.2.14/mpm-worker
...

pstack output:
 ff0cc1d4 __pollsys (ffbf9688, 0, ffbf96f0, 0, 0, 0) + 8
 ff067b68 pselect  (ffbf9688, ff134630, ff134630, 0, ffbf96f0, 0) + 1c8
 ff067ee0 select   (0, 0, 0, 0, ffbf9758, 7a120) + a0
 ff2fbf74 apr_sleep (7a120, 0, 0, 0, 0, 20000) + 78
 0005e794 ???????? (10cb10, 14bfc8, 0, 77f30, 0, 8d000)
 0005ebec ???????? (1d4c1, 10bec8, 8fc00, 8d000, 8d280, 2)
 0005f170 ???????? (9cad0, 0, 0, ffffffff, 1, 8d000)
 0005f20c ???????? (2, 14bf70, 90000, 8d000, 0, 0)
 0005ffc0 ap_mpm_run (2, 4, 0, 8d258, 0, 8fdcc) + 1e8
 0002925c main     (0, 8bc00, 8d000, 98c60, 707a0, 0) + a1c
 00028728 _start   (0, 0, 0, 0, 0, 0) + 108

but only if worker is been used (event and prefork work so far). Applied the patch and this fixed it. This is a "Solaris 10 5/09 s10s_u7wos_08 SPARC Generic_139555-08 sun4u".

Thank you very much!
Comment 20 Jeff Trawick 2009-11-13 19:26:56 UTC
now fixed in apr 1.3 branch
Comment 21 Karen Ezzo 2012-01-17 20:58:21 UTC
I am experiencing a very similar problem but I am on apache 2.2.17. I have been seeing these messages in the error_log:
[Thu Jan 12 09:23:12 2012] [notice] child pid 16000 exit signal Segmentation fault (11), possible coredump in /usr/local/apache2/

I am relatively new to troubleshooting apache but did manage to run a coredump file thru gdb. However, my output is different than previous posts:

gdb /usr/local/apache2/bin/httpd core_UWB00022_httpd_1_12_1326415454_437
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10"...
Error while mapping shared library sections:
/opt/ISS/lib/mod_rs.so: No such file or directory.
Error while mapping shared library sections:
/opt/ISS/lib/libstdc++.so.5: No such file or directory.
Error while mapping shared library sections:
/opt/ISS/lib/libgcc_s.so.1: No such file or directory.
Reading symbols from /lib/libdl.so.1...
warning: Lowest section in /lib/libdl.so.1 is .hash at 000000b4
done.
Loaded symbols for /lib/libdl.so.1
Reading symbols from /lib/libm.so.2...done.
Loaded symbols for /lib/libm.so.2
Reading symbols from /usr/local/apache2/lib/libaprutil-1.so.0...done.
Loaded symbols for /usr/local/apache2//lib/libaprutil-1.so.0
Reading symbols from /usr/local/apache2/lib/libexpat.so.0...done.
Loaded symbols for /usr/local/apache2//lib/libexpat.so.0
Reading symbols from /usr/local/lib/libiconv.so.2...done.
Loaded symbols for /usr/local/lib/libiconv.so.2
Reading symbols from /usr/local/apache2/lib/libapr-1.so.0...done.
Loaded symbols for /usr/local/apache2//lib/libapr-1.so.0
Reading symbols from /lib/libuuid.so.1...done.
Loaded symbols for /lib/libuuid.so.1
Reading symbols from /lib/libsendfile.so.1...done.
Loaded symbols for /lib/libsendfile.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libsocket.so.1...done.
Loaded symbols for /lib/libsocket.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libpthread.so.1...
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074
done.
Loaded symbols for /lib/libpthread.so.1
Reading symbols from /lib/libc.so.1...done.
Loaded symbols for /lib/libc.so.1
Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/lib/libgcc_s.so.1
Reading symbols from /lib/libaio.so.1...done.
Loaded symbols for /lib/libaio.so.1
Reading symbols from /lib/libmd.so.1...done.
Loaded symbols for /lib/libmd.so.1
Reading symbols from /platform/sun4v/lib/libc_psr.so.1...done.
Loaded symbols for /platform/SUNW,T5140/lib/libc_psr.so.1
Reading symbols from /lib/libgen.so.1...done.
Loaded symbols for /lib/libgen.so.1
Reading symbols from /lib/libscf.so.1...done.
Loaded symbols for /lib/libscf.so.1
Reading symbols from /lib/libdoor.so.1...done.
Loaded symbols for /lib/libdoor.so.1
Reading symbols from /lib/libuutil.so.1...done.
Loaded symbols for /lib/libuutil.so.1
Reading symbols from /platform/sun4v/lib/libmd_psr.so.1...done.
Loaded symbols for /platform/SUNW,T5140/lib/libmd_psr.so.1
Reading symbols from /lib/libmp.so.2...done.
Loaded symbols for /lib/libmp.so.2
Reading symbols from /lib/nss_files.so.1...done.
Loaded symbols for /lib/nss_files.so.1
Reading symbols from /lib/nss_dns.so.1...done.
Loaded symbols for /lib/nss_dns.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Symbol file not found for /opt/ISS/lib/mod_rs.so
Symbol file not found for /opt/ISS/lib/libstdc++.so.5
Reading symbols from /lib/libm.so.1...done.
Loaded symbols for /lib/libm.so.1
Symbol file not found for /opt/ISS/lib/libgcc_s.so.1
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal 11, Segmentation fault.
[New process 65973    ]
#0  0xfe1655ec in ?? ()
(gdb) where
#0  0xfe1655ec in ?? ()
#1  0xfed91804 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

In searching for this last "Backtrace stopped..." message, i found this apache bug (48030). Can anyone tell me if this is or is not the same problem?  If so, is the above mentioned patch applicable since I am at apache 2.2.17?  If not, any further suggestions would be much appreciated!

Karen
Comment 22 Eric Covener 2012-01-17 21:54:22 UTC
Karen, please open a new bugreport, or ask for assistance on a mailing list on how to get a useful backtrace.
Comment 23 William A. Rowe Jr. 2012-01-17 21:56:07 UTC
Those experiencing problems need to update to the latest APR 1.x version
(APR 1.4.5 at the time I'm typing this response).  It is good but not necessary 
to update httpd at the same time.  Building an older httpd release potentially
installs an old apr version.  

The  apr-1-config --version  command should report the installed version.

Downloads can be found at http://apr.apache.org/download.cgi
Comment 24 karen ezzo 2012-01-19 14:31:01 UTC
We are currently at apr 1.4.2. I will apply the upgrade and update this ticket with the outcome. Thank you
viis_ops@UWB00022:/export/home/viis_ops>
Comment 25 karen ezzo 2012-01-23 18:52:56 UTC
I upgraded the apr but am still experiencing the same issue:

viis_ops@UWB00022:/export/home/viis_ops>apr-1-config --version
1.4.5
viis_ops@UWB00022:/export/home/viis_ops>

gdb /usr/local/apache2/bin/httpd core_UWB00022_httpd_1_12_1327342375_21113
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10"...
.
.
.
.
Core was generated by `/usr/local/apache2/bin/httpd -k start'.
Program terminated with signal 11, Segmentation fault.
[New process 86649    ]
#0  0xfe1655ec in ?? ()
(gdb) where
#0  0xfe1655ec in ?? ()
#1  0xfec81804 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
Comment 26 Eric Covener 2012-01-23 19:17:11 UTC
Karen, you must open your own bug report.