You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Ishita Kapadiya <is...@gmail.com> on 2012/05/30 00:11:06 UTC
[users@httpd] Segmentation fault error
Hi All,
I am using this configurations -
Solaris sparc 10/apache 2.2.22/openssl 1.0.0g/simteminder sso/mod-jk 1.30
we are curently running multiple apache servers from the apache's root dir.
Only one of the those instances throwing below errors in error_log :
[Tue May 19 16:14:06 2012] [notice] child pid 15729 exit signal Bus error (10)
[Tue May 19 17:46:24 2012] [notice] child pid 17114 exit signal
Segmentation fault (11), possible coredump in /tmp/core
we had recently upgraded apache to 2.2.22 version and since then we
are seeing above errors. I am not sure what could be the reason. the
other instances don't have any problems whereas all instances are
using the same modules!
So i have enabled core dump and here is the o/p -
pstack core.httpd.17114
core 'core.httpd.17114' of 17114: /abc/apache-2.2.22/bin/httpd
-f /abc/apache-2.2.22/<instance name>/co
----------------- lwp# 1 / thread# 1 --------------------
fef45874 _read (6, ffbff5e3, 1, 0, 10b4, fef73ac0) + c
0006b714 ap_mpm_pod_check (d6800, 68764, 68f8c, 1b7ec0, 0, 1) + 18
000697b4 child_main (0, 682dc, 0, fee58000, fef73700, fedf2a00) + 2d4
00069930 make_child (9bc00, 0, 1, 9cc00, 9b400, 9c800) + 128
0006a160 ap_mpm_run (fe720058, 4, 0, a, 1, 0) + 740
00029bc8 main (a7810, 99c00, 9bc00, 9bc00, a5808, 0) + 77c
00028f7c _start (0, 0, 0, 0, 0, 0) + 5c
----------------- lwp# 2 / thread# 2 --------------------
ff221518 ????????(), exit value = 0x00000000
** zombie (exited, not detached, not yet joined) **
----------------- lwp# 3 / thread# 3 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fdf7bf1c, fdf7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8170, 0, 0, 9c800, 9c800, 0) + 10c
ff221524 ???????? (1b8170, fdf7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 4 / thread# 4 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fde7bf1c, fde7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8190, 0, 0, 9c800, 9c800, 4) + 10c
ff221524 ???????? (1b8190, fde7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 5 / thread# 5 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2f5af0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fdd7bf1c, fdd7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b81b0, 0, 0, 9c800, 9c800, 8) + 10c
ff221524 ???????? (1b81b0, fdd7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 6 / thread# 6 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2e7ab8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fdc7bf1c, fdc7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b81d0, 0, 0, 9c800, 9c800, c) + 10c
ff221524 ???????? (1b81d0, fdc7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 7 / thread# 7 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2e7ab8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fdb7bf1c, fdb7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b81f0, 0, 0, 9c800, 9c800, 10) + 10c
ff221524 ???????? (1b81f0, fdb7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 8 / thread# 8 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fda7bf1c, fda7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8210, 0, 0, 9c800, 9c800, 14) + 10c
ff221524 ???????? (1b8210, fda7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 9 / thread# 9 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2e7ab8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd97bf1c, fd97bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8230, 0, 0, 9c800, 9c800, 18) + 10c
ff221524 ???????? (1b8230, fd97c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 10 / thread# 10 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd87bf1c, fd87bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8250, 0, 0, 9c800, 9c800, 1c) + 10c
ff221524 ???????? (1b8250, fd87c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 11 / thread# 11 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd77bf1c, fd77bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8270, 0, 0, 9c800, 9c800, 20) + 10c
ff221524 ???????? (1b8270, fd77c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 12 / thread# 12 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd67bf1c, fd67bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8290, 0, 0, 9c800, 9c800, 24) + 10c
ff221524 ???????? (1b8290, fd67c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 13 / thread# 13 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd57bf1c, fd57bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b82b0, 0, 0, 9c800, 9c800, 28) + 10c
ff221524 ???????? (1b82b0, fd57c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 14 / thread# 14 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd47bf1c, fd47bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b82d0, 0, 0, 9c800, 9c800, 2c) + 10c
ff221524 ???????? (1b82d0, fd47c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 15 / thread# 15 --------------------
0002e26c ap_escape_logitem (30f4f8, 76370, 309450, 1, 2000, 0) + 80
00050068 config_log_transaction (336768, d4b18, 0, 9ce78, d2450, d3210) + 16c
00050198 multi_log_transaction (336768, 30f478, c40, 0, 9bf54, d65c8) + 4c
00030b80 ap_run_log_transaction (336768, c, 6, 336768, 0, 2e7d70) + 3c
0005558c ap_process_request (336768, 30f478, 4, 336768, 9c818, 2e7dd0) + dc
0005269c ap_process_http_connection (2e7d70, 2e7ac0, 2e7ac0, c,
9c818, d6680) + 10c
000434e8 ap_run_process_connection (2e7d70, 2e7ac0, 2e7ac0, c,
2e7d68, 2eba88) + 3c
00068edc worker_thread (1b82f0, 0, 0, 9c800, 9c800, 30) + 20c
ff221524 ???????? (1b82f0, fd37c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 16 / thread# 16 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2e7ab8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd27bf1c, fd27bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8310, 0, 0, 9c800, 9c800, 34) + 10c
ff221524 ???????? (1b8310, fd27c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 17 / thread# 17 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd17bf1c, fd17bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8330, 0, 0, 9c800, 9c800, 38) + 10c
ff221524 ???????? (1b8330, fd17c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 18 / thread# 18 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fd07bf1c, fd07bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8350, 0, 0, 9c800, 9c800, 3c) + 10c
ff221524 ???????? (1b8350, fd07c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 19 / thread# 19 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fcf7bf1c, fcf7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8370, 0, 0, 9c800, 9c800, 40) + 10c
ff221524 ???????? (1b8370, fcf7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 20 / thread# 20 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fce7bf1c, fce7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8390, 0, 0, 9c800, 9c800, 44) + 10c
ff221524 ???????? (1b8390, fce7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 21 / thread# 21 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fcd7bf1c, fcd7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b83b0, 0, 0, 9c800, 9c800, 48) + 10c
ff221524 ???????? (1b83b0, fcd7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 22 / thread# 22 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fcc7bf1c, fcc7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b83d0, 0, 0, 9c800, 9c800, 4c) + 10c
ff221524 ???????? (1b83d0, fcc7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 23 / thread# 23 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 2efad8) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fcb7bf1c, fcb7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b83f0, 0, 0, 9c800, 9c800, 50) + 10c
ff221524 ???????? (1b83f0, fcb7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 24 / thread# 24 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fca7bf1c, fca7bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8410, 0, 0, 9c800, 9c800, 54) + 10c
ff221524 ???????? (1b8410, fca7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 25 / thread# 25 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fc97bf1c, fc97bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8430, 0, 0, 9c800, 9c800, 58) + 10c
ff221524 ???????? (1b8430, fc97c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 26 / thread# 26 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fc87bf1c, fc87bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8450, 0, 0, 9c800, 9c800, 5c) + 10c
ff221524 ???????? (1b8450, fc87c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 27 / thread# 27 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fc77bf1c, fc77bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8470, 0, 0, 9c800, 9c800, 60) + 10c
ff221524 ???????? (1b8470, fc77c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 28 / thread# 28 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fc67bf1c, fc67bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8490, 0, 0, 9c800, 9c800, 64) + 10c
ff221524 ???????? (1b8490, fc67c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 29 / thread# 29 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fc57bf1c, fc57bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b84b0, 0, 0, 9c800, 9c800, 68) + 10c
ff221524 ???????? (1b84b0, fc57c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 30 / thread# 30 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fc47bf1c, fc47bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b84d0, 0, 0, 9c800, 9c800, 6c) + 10c
ff221524 ???????? (1b84d0, fc47c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 31 / thread# 31 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fc37bf1c, fc37bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b84f0, 0, 0, 9c800, 9c800, 70) + 10c
ff221524 ???????? (1b84f0, fc37c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 32 / thread# 32 --------------------
fef44a34 __lwp_park (1b7f58, 1b7f28, 0, 0, 0, 0) + 14
fef3ea7c cond_wait_queue (1b7f58, 1b7f28, 0, 0, 0, 0) + 28
fef3effc cond_wait (1b7f58, 1b7f28, 0, 2, 1, 34e1d0) + 10
fef3f038 pthread_cond_wait (1b7f58, 1b7f28, 0, 1000, 0, 0) + 8
0006b5e8 ap_queue_pop (1b7f08, fc27bf1c, fc27bf18, 0, 0, 1b80f8) + 64
00068ddc worker_thread (1b8510, 0, 0, 9c800, 9c800, 74) + 10c
ff221524 ???????? (1b8510, fc27c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 33 / thread# 33 --------------------
fef44e94 _portfs (11, 126998, 2, fc17bdf4, 0, 126a10) + 8
ff21c860 call_port_getn (0, 126998, 2, fc17bdf4, ffffffff, ffffffff) + 7c
ff21ce48 impl_pollset_poll (126928, ffffffff, ffffffff, fc17befc,
fc17bef8, 0) + 10c
ff21c738 apr_pollset_poll (126928, ffffffff, ffffffff, fc17befc,
fc17bef8, a6378) + 1c
000688b8 listener_thread (9c800, 0, 9c800, 9bc00, 85400, 1) + 14c
ff221524 ???????? (1b8530, fc17c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 35 / thread# 35 --------------------
fef45760 __pollsys (fe07bdf8, 0, fe07be60, 0, 0, 0) + 8
feee6cc0 pselect (fe07bdf8, fef72528, fef72528, 0, fe07be60, 0) + 1c8
feee7038 select (0, 0, 0, 0, fe07bee8, 0) + a0
fe5ead5c __1cIcm_sleep6FLl_v_ (1, 0, 0, 0, 0, 0) + 5c
fe5ec020 ConnectionService (318810, b20c, a9c4, ade8, 318a38, fe6a70dc) + 350
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 36 / thread# 36 --------------------
fef45760 __pollsys (fab7be28, 0, fab7be90, 0, 0, 0) + 8
feee6cc0 pselect (fab7be28, fef72528, fef72528, 0, fab7be90, 0) + 1c8
feee7038 select (0, 0, 0, 0, fab7bf18, fab7bef0) + a0
fe5d72d8 __1cPCSmWorkerThreadFSleep6MLl_v_ (0, 1, 0, 0, 0, 0) + 5c
fe5a1b40 __1cPCSmAdminManagerRManageAgentThread6Fpv_1_ (0, 31a858, 1,
31a858, fe5a1af0, 33abd0) + 50
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
could anybody please point me to the right direction and possible root
cause of the error? (I don't know how to use mdb which is installed on
our server)
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Segmentation fault error
Posted by Ishita Kapadiya <is...@gmail.com>.
Hi Eric,
could you please let me know the next steps to mitigate Segfault error..
On Wed, May 30, 2012 at 6:30 PM, Eric Covener <co...@gmail.com> wrote:
> On Wed, May 30, 2012 at 5:59 PM, Ishita Kapadiya <is...@gmail.com> wrote:
>> Thanks William. This is the stack output i got from mdb when core got
>> dumped. Also, when i google "ap_mpm_pod_check" then got to know that
>> there are lots of people who hits Apache bug.
>
> It means lots of people post about the first thread that shows up in
> gdb/dbx/pstack
>
> --
> Eric Covener
> covener@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Segmentation fault error
Posted by Eric Covener <co...@gmail.com>.
On Wed, May 30, 2012 at 5:59 PM, Ishita Kapadiya <is...@gmail.com> wrote:
> Thanks William. This is the stack output i got from mdb when core got
> dumped. Also, when i google "ap_mpm_pod_check" then got to know that
> there are lots of people who hits Apache bug.
It means lots of people post about the first thread that shows up in
gdb/dbx/pstack
--
Eric Covener
covener@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Segmentation fault error
Posted by Ishita Kapadiya <is...@gmail.com>.
Thanks William. This is the stack output i got from mdb when core got
dumped. Also, when i google "ap_mpm_pod_check" then got to know that
there are lots of people who hits Apache bug.
Please refer this URL - http://www.gossamer-threads.com/lists/apache/bugs/414768
Also, i ran pfiles against the core file and i got
data model = _ILP32 flags = MSACCT|MSFORK
/1: flags = 0
sigmask = 0xffffbeff,0x0000ffff cursig = SIGSEGV
/2: <defunct>
/3: flags = STOPPED lwp_park(0x4,0x0,0x0)
why = PR_SUSPENDED
sigmask = 0xffbe6007,0x0000fff7
.. (rest of lines truncted)
I don't know much about debugging as i am not from developer
background but whatever o/p i got, looks like some bug with Apache
2.2.22.
Please revert.
On Wed, May 30, 2012 at 4:43 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> You didn't dump the offending stack, you dumped the first stack. It's highly
> unlikely there was a segfault in _read.
>
> You need to dump all the thread stacks, and work out the offending one; this is
> usuallly designated <<< FAULT or some other indication of where the fault occured.
>
> On 5/30/2012 10:32 AM, Ishita Kapadiya wrote:
>> Thanks Nick.
>> I have compiled Apache for myself both the time and both are 32-bit.
>> The same modules all other instances are using and thus i am not sure
>> what is different with this instance that causing Segmentation fault
>> error.
>>
>> I tried to dig more into it and here is what i got -
>>
>> mdb core
>>> ::stack
>> libc.so.1`_read+0xc(6, ffbff5e3, 1, 0, 10b4, fef73ac0)
>> ap_mpm_pod_check+0x18(d6800, 68764, 68f8c, 1b7ec0, 0, 1)
>> child_main+0x2d4(0, 682dc, 0, fee58000, fef73700, fedf2a00)
>> make_child+0x128(9bc00, 0, 1, 9cc00, 9b400, 9c800)
>> ap_mpm_run+0x740(fe720058, 4, 0, a, 1, 0)
>> main+0x77c(a7810, 99c00, 9bc00, 9bc00, a5808, 0)
>> _start+0x5c(0, 0, 0, 0, 0, 0)
>>
>> pstack core
>> fef45874 _read (6, ffbff5e3, 1, 0, 10b4, fef73ac0) + c
>> 0006b714 ap_mpm_pod_check (d6800, 68764, 68f8c, 1b7ec0, 0, 1) + 18
>> 000697b4 child_main (0, 682dc, 0, fee58000, fef73700, fedf2a00) + 2d4
>> 00069930 make_child (9bc00, 0, 1, 9cc00, 9b400, 9c800) + 128
>> 0006a160 ap_mpm_run (fe720058, 4, 0, a, 1, 0) + 740
>> 00029bc8 main (a7810, 99c00, 9bc00, 9bc00, a5808, 0) + 77c
>> 00028f7c _start (0, 0, 0, 0, 0, 0) + 5c
>>
>> pmap core
>> 00010000 448K r-x-- /abc/apache-2.2.22/bin/httpd
>> 00080000 32K r-x--
>> 00096000 24K rwx-- /abc/apache-2.2.22/bin/httpd
>> 0009C000 16K rwx-- /abc/apache-2.2.22/bin/httpd
>> 000A0000 6528K rwx-- [ heap ]
>> FAB7A000 8K rw--- [ stack tid=36 ]
>> ...
>> (removed rest of the lines to avoid length)
>>
>> mdb /abc/apache-2.2.22/bin/httpd
>>
>>> ::dis ap_mpm_pod_check!head
>> ap_mpm_pod_check: save %sp, -0x78, %sp
>> ap_mpm_pod_check+4: ld [%i0], %o1
>> ap_mpm_pod_check+8: call +0x2d0e0 <PLT:apr_os_file_get>
>> ap_mpm_pod_check+0xc: add %fp, -0x14, %o0
>> ap_mpm_pod_check+0x10: ld [%fp - 0x14], %o0
>> ap_mpm_pod_check+0x14: add %fp, -0x15, %o1
>> ap_mpm_pod_check+0x18: call +0x2cdc4 <PLT:read>
>> ap_mpm_pod_check+0x1c: mov 1, %o2
>>
>> Please help me what could be the problem? It's affecting my production
>> env and i really don't know what to do next?
>>
>> On Tue, May 29, 2012 at 7:15 PM, Nick Kew <ni...@webthing.com> wrote:
>>>
>>> On 29 May 2012, at 23:11, Ishita Kapadiya wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am using this configurations -
>>>>
>>>> Solaris sparc 10/apache 2.2.22/openssl 1.0.0g/simteminder sso/mod-jk 1.30
>>>
>>> Did you compile everything yourself?
>>>
>>> If yes, could any compile options have changed? E.g. between 32-bit and 64-bit,
>>> or something less obvious but just as important?
>>>
>>> If no, what suppliers do your binaries come from, and have you checked with them?
>>>
>>> --
>>> Nick Kew
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Segmentation fault error
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
You didn't dump the offending stack, you dumped the first stack. It's highly
unlikely there was a segfault in _read.
You need to dump all the thread stacks, and work out the offending one; this is
usuallly designated <<< FAULT or some other indication of where the fault occured.
On 5/30/2012 10:32 AM, Ishita Kapadiya wrote:
> Thanks Nick.
> I have compiled Apache for myself both the time and both are 32-bit.
> The same modules all other instances are using and thus i am not sure
> what is different with this instance that causing Segmentation fault
> error.
>
> I tried to dig more into it and here is what i got -
>
> mdb core
>> ::stack
> libc.so.1`_read+0xc(6, ffbff5e3, 1, 0, 10b4, fef73ac0)
> ap_mpm_pod_check+0x18(d6800, 68764, 68f8c, 1b7ec0, 0, 1)
> child_main+0x2d4(0, 682dc, 0, fee58000, fef73700, fedf2a00)
> make_child+0x128(9bc00, 0, 1, 9cc00, 9b400, 9c800)
> ap_mpm_run+0x740(fe720058, 4, 0, a, 1, 0)
> main+0x77c(a7810, 99c00, 9bc00, 9bc00, a5808, 0)
> _start+0x5c(0, 0, 0, 0, 0, 0)
>
> pstack core
> fef45874 _read (6, ffbff5e3, 1, 0, 10b4, fef73ac0) + c
> 0006b714 ap_mpm_pod_check (d6800, 68764, 68f8c, 1b7ec0, 0, 1) + 18
> 000697b4 child_main (0, 682dc, 0, fee58000, fef73700, fedf2a00) + 2d4
> 00069930 make_child (9bc00, 0, 1, 9cc00, 9b400, 9c800) + 128
> 0006a160 ap_mpm_run (fe720058, 4, 0, a, 1, 0) + 740
> 00029bc8 main (a7810, 99c00, 9bc00, 9bc00, a5808, 0) + 77c
> 00028f7c _start (0, 0, 0, 0, 0, 0) + 5c
>
> pmap core
> 00010000 448K r-x-- /abc/apache-2.2.22/bin/httpd
> 00080000 32K r-x--
> 00096000 24K rwx-- /abc/apache-2.2.22/bin/httpd
> 0009C000 16K rwx-- /abc/apache-2.2.22/bin/httpd
> 000A0000 6528K rwx-- [ heap ]
> FAB7A000 8K rw--- [ stack tid=36 ]
> ...
> (removed rest of the lines to avoid length)
>
> mdb /abc/apache-2.2.22/bin/httpd
>
>> ::dis ap_mpm_pod_check!head
> ap_mpm_pod_check: save %sp, -0x78, %sp
> ap_mpm_pod_check+4: ld [%i0], %o1
> ap_mpm_pod_check+8: call +0x2d0e0 <PLT:apr_os_file_get>
> ap_mpm_pod_check+0xc: add %fp, -0x14, %o0
> ap_mpm_pod_check+0x10: ld [%fp - 0x14], %o0
> ap_mpm_pod_check+0x14: add %fp, -0x15, %o1
> ap_mpm_pod_check+0x18: call +0x2cdc4 <PLT:read>
> ap_mpm_pod_check+0x1c: mov 1, %o2
>
> Please help me what could be the problem? It's affecting my production
> env and i really don't know what to do next?
>
> On Tue, May 29, 2012 at 7:15 PM, Nick Kew <ni...@webthing.com> wrote:
>>
>> On 29 May 2012, at 23:11, Ishita Kapadiya wrote:
>>
>>> Hi All,
>>>
>>> I am using this configurations -
>>>
>>> Solaris sparc 10/apache 2.2.22/openssl 1.0.0g/simteminder sso/mod-jk 1.30
>>
>> Did you compile everything yourself?
>>
>> If yes, could any compile options have changed? E.g. between 32-bit and 64-bit,
>> or something less obvious but just as important?
>>
>> If no, what suppliers do your binaries come from, and have you checked with them?
>>
>> --
>> Nick Kew
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Segmentation fault error
Posted by Ishita Kapadiya <is...@gmail.com>.
Thanks Nick.
I have compiled Apache for myself both the time and both are 32-bit.
The same modules all other instances are using and thus i am not sure
what is different with this instance that causing Segmentation fault
error.
I tried to dig more into it and here is what i got -
mdb core
> ::stack
libc.so.1`_read+0xc(6, ffbff5e3, 1, 0, 10b4, fef73ac0)
ap_mpm_pod_check+0x18(d6800, 68764, 68f8c, 1b7ec0, 0, 1)
child_main+0x2d4(0, 682dc, 0, fee58000, fef73700, fedf2a00)
make_child+0x128(9bc00, 0, 1, 9cc00, 9b400, 9c800)
ap_mpm_run+0x740(fe720058, 4, 0, a, 1, 0)
main+0x77c(a7810, 99c00, 9bc00, 9bc00, a5808, 0)
_start+0x5c(0, 0, 0, 0, 0, 0)
pstack core
fef45874 _read (6, ffbff5e3, 1, 0, 10b4, fef73ac0) + c
0006b714 ap_mpm_pod_check (d6800, 68764, 68f8c, 1b7ec0, 0, 1) + 18
000697b4 child_main (0, 682dc, 0, fee58000, fef73700, fedf2a00) + 2d4
00069930 make_child (9bc00, 0, 1, 9cc00, 9b400, 9c800) + 128
0006a160 ap_mpm_run (fe720058, 4, 0, a, 1, 0) + 740
00029bc8 main (a7810, 99c00, 9bc00, 9bc00, a5808, 0) + 77c
00028f7c _start (0, 0, 0, 0, 0, 0) + 5c
pmap core
00010000 448K r-x-- /abc/apache-2.2.22/bin/httpd
00080000 32K r-x--
00096000 24K rwx-- /abc/apache-2.2.22/bin/httpd
0009C000 16K rwx-- /abc/apache-2.2.22/bin/httpd
000A0000 6528K rwx-- [ heap ]
FAB7A000 8K rw--- [ stack tid=36 ]
...
(removed rest of the lines to avoid length)
mdb /abc/apache-2.2.22/bin/httpd
> ::dis ap_mpm_pod_check!head
ap_mpm_pod_check: save %sp, -0x78, %sp
ap_mpm_pod_check+4: ld [%i0], %o1
ap_mpm_pod_check+8: call +0x2d0e0 <PLT:apr_os_file_get>
ap_mpm_pod_check+0xc: add %fp, -0x14, %o0
ap_mpm_pod_check+0x10: ld [%fp - 0x14], %o0
ap_mpm_pod_check+0x14: add %fp, -0x15, %o1
ap_mpm_pod_check+0x18: call +0x2cdc4 <PLT:read>
ap_mpm_pod_check+0x1c: mov 1, %o2
Please help me what could be the problem? It's affecting my production
env and i really don't know what to do next?
On Tue, May 29, 2012 at 7:15 PM, Nick Kew <ni...@webthing.com> wrote:
>
> On 29 May 2012, at 23:11, Ishita Kapadiya wrote:
>
>> Hi All,
>>
>> I am using this configurations -
>>
>> Solaris sparc 10/apache 2.2.22/openssl 1.0.0g/simteminder sso/mod-jk 1.30
>
> Did you compile everything yourself?
>
> If yes, could any compile options have changed? E.g. between 32-bit and 64-bit,
> or something less obvious but just as important?
>
> If no, what suppliers do your binaries come from, and have you checked with them?
>
> --
> Nick Kew
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Segmentation fault error
Posted by Nick Kew <ni...@webthing.com>.
On 29 May 2012, at 23:11, Ishita Kapadiya wrote:
> Hi All,
>
> I am using this configurations -
>
> Solaris sparc 10/apache 2.2.22/openssl 1.0.0g/simteminder sso/mod-jk 1.30
Did you compile everything yourself?
If yes, could any compile options have changed? E.g. between 32-bit and 64-bit,
or something less obvious but just as important?
If no, what suppliers do your binaries come from, and have you checked with them?
--
Nick Kew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org