You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2012/05/30 15:11:55 UTC
[Bug 53329] New: Segmentation fault in ap_mpm_pod_check() method
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
Priority: P2
Bug ID: 53329
Assignee: bugs@httpd.apache.org
Summary: Segmentation fault in ap_mpm_pod_check() method
Severity: critical
Classification: Unclassified
OS: Solaris
Reporter: bunkap@email.cz
Hardware: Sun
Status: NEW
Version: 2.2.22
Component: mpm_worker
Product: Apache httpd-2
Apache httpd consistently crashing on Solaris SPARC. The processes are OK
during one week. But some day, the processes are dying almost every minute. It
has been found, that it is during read() operation in
mpm_worker:ap_mpm_pod_check() method.
I use the last 2.2 version:
/opt/csw/apache2/sbin/httpd -V
Server version: Apache/2.2.22 (Unix)
Server built: Apr 14 2012 04:26:36
Server's Module Magic Number: 20051115:30
Server loaded: APR 1.4.5, APR-Util 1.3.12
Compiled using: APR 1.4.6, APR-Util 1.3.12
Architecture: 32-bit
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_FCNTL_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/opt/csw/apache2"
-D SUEXEC_BIN="/opt/csw/apache2/bin/suexec"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="etc/mime.types"
-D SERVER_CONFIG_FILE="etc/httpd.conf"
There is always only one line at the time of crash at error log:
[Wed May 30 12:40:32 2012] [notice] child pid 13661 exit signal Segmentation
fault (11), possible coredump in /opt/csw/apache2
pstack of coredump contains message about zombie:
----------------- lwp# 2 / thread# 2 --------------------
ff123468 dummy_worker(), exit value = 0x00000000
** zombie (exited, not detached, not yet joined) **
callstack retrieved from coredump by dbx:
current thread: t@1
=>[1] libc.so.1:_read(0x4, 0xffbff70b, 0x1, 0x0, 0xffbff630, 0x1), at
0xfedcd39c
[2] libc.so.1:read(0x9, 0xffbff70b, 0x1, 0x0, 0x1cf4, 0x9), at 0xfedbbaa4
[3] httpd.worker:ap_mpm_pod_check(0x197e50, 0x50610, 0x2, 0x0, 0x0, 0x1), at
0x53878
[4] 0x51698(0x0, 0x1d4c1, 0x7f284, 0x7c790, 0x7f278, 0xb4268), at 0x51698
[5] 0x5181c(0x8bf88, 0x0, 0xffffffff, 0x0, 0x7c400, 0x0), at 0x5181c
[6] 0x51f14(0x0, 0x1, 0x1, 0x1, 0x7400, 0x0), at 0x51f14
[7] 0x52208(0x0, 0x0, 0xffffffff, 0x80, 0xffbff938, 0xffbff948), at 0x52208
[8] httpd.worker:ap_mpm_run(0x0, 0xfffffe99, 0x99, 0x7c768, 0x7f26c,
0x7f400), at 0x524d0
[9] httpd.worker:main(0x7b3d8, 0x7c400, 0x46c80, 0x7c5dc, 0xffbffa28,
0x7c5ec), at 0x2a34c
I'm not sure, but it may be the same problem as in bug 52510.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #9 from bunkap@email.cz ---
Thanks Maulik for another info and Stefan for help.
I read another coredump in mdb. It again crash at read() in ap_mpm_pod_check():
# mdb core.httpd.worker.16578
Loading modules: [ libc.so.1 libuutil.so.1 ld.so.1 ]
> ::status
debugging core file of httpd.worker (32-bit) from web1
file: /opt/csw/apache2/sbin/httpd.worker
initial argv: /opt/csw/apache2/sbin/httpd -f /opt/csw/apache2/etc/httpd.conf -k
start -DSSL
threading model: multi-threaded
status: process terminated by SIGSEGV (Segmentation Fault)
> ::stack
libc.so.1`_read+0xc(9, ffbff70b, 1, 0, 1cf4, 9)
ap_mpm_pod_check+0x18(1fcfd0, 50610, 2, 0, 0, 1)
0x51698(0, 1d4c1, 7f284, 7c790, 7f278, 157818)
0x5181c(8bf88, 0, ffffffff, 0, 7c400, 0)
0x51f14(0, 1, 1, 1, 7400, 0)
0x52208(0, 0, ffffffff, 80, ffbff938, ffbff948)
ap_mpm_run+0x298(0, fffffe99, 99, 7c768, 7f26c, 7f400)
main+0x8e4(7b3d8, 7c400, 46c80, 7c5dc, ffbffa28, 7c5ec)
_start+0x108(0, 0, 0, 0, 0, 0)
Is any chance to solve this bug? It is big stability problem on Solaris 10.
What should I do, to have more info about crash?
Thank you
bunkap
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #5 from Maulik <ma...@gmail.com> ---
Hi Stefan,
Could you please help on this error?
Thanks
Maulik
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #10 from Maulik <ma...@gmail.com> ---
My problem got resolved. It turned out to be one of the modules that we have
written causing the problem. I have disabled that module and that did the
trick. Actully, the same module was running fine with 2.2.9 so that made me
curious what got changed that causing the issue.
Remember, i had also mentioned that i had lots of wiered entries in the logs in
the first column (where it supposed to show remote client IP?). So when i
checked the mod_log_config.c, it seems one option had been added (-k) which was
not there in 2.2.9 and some how that's causing conflict with our custom module.
By the way, custome module was changing the remote ip to one we are passing
through config for security reason. But we have used work around and disable
that plug-in.
Thanks Stefan for acknowledging that "wiered log entries could lead to
Segmentation error".
I think we could have resolved the issue by increasing length for below
mentioned two parameters, but that needs rebuilding of Apache -
LimitRequestFieldSize
LimitRequestLine
Hope, that helps to some one who are facing such issues given the similar
situation!
Thanks
Maulik
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #2 from Stefan Fritsch <sf...@sfritsch.de> ---
(In reply to comment #1)
> I am also facing the same problem as mentioned. I have seen couple of users
> also reported the same issue on Apache users site as well.
>
> Can someone please look into this? I can provide all data if you want.
Hi Maulik,
is your httpd version also 2.2.22? What is the LogFormat line that is used for
this request?
Do you have some symbolic debugger like gdb that can display the line numbers
and local variables in the stack trace?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #7 from Maulik <ma...@gmail.com> ---
Thanks Stefan.
Is it good idea to recompile apache and setup the instance in which we are
seeing this problem?
Thanks
Maulik
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
Maulik <ma...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |maulik.linuxsysadmin@gmail.
| |com
--- Comment #1 from Maulik <ma...@gmail.com> ---
Hi,
I am also facing the same problem as mentioned. I have seen couple of users
also reported the same issue on Apache users site as well.
Can someone please look into this? I can provide all data if you want.
mdb core -
> ::stack
libc.so.1`_read+0xc(6, ffbff783, 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(fe7a0058, 4, 0, a, 1, 0)
main+0x77c(a7810, 99c00, 9bc00, 9bc00, a5808, 0)
_start+0x5c(0, 0, 0, 0, 0, 0)
When I ran truss against PID, i got SIGSEGV for thread @ 20 and thus I am
including pstack and truss o/p for details. (I have full truss available for
20693/20. Please let me know if someone wants to dig further)
pstack core -
----------------- lwp# 20 / thread# 20 --------------------
0002e26c ap_escape_logitem (544dd0, 76370, 540dc0, 1, 2000, 0) + 80
00050068 config_log_transaction (54be10, d4b18, 0, 9ce78, d2450, d3210) + 16c
00050198 multi_log_transaction (54be10, 544d50, c40, 0, 9bf54, d65c8) + 4c
00030b80 ap_run_log_transaction (54be10, 11, 6, 54be10, 0, 56eb50) + 3c
0005558c ap_process_request (54be10, 544d50, 4, 54be10, 9c818, 56ebb0) + dc
0005269c ap_process_http_connection (56eb50, 56e8a0, 56e8a0, 11, 9c818, d6680)
+ 10c
000434e8 ap_run_process_connection (56eb50, 56e8a0, 56e8a0, 11, 56eb48,
53ada8) + 3c
00068edc worker_thread (1b8390, 0, 0, 9c800, 9c800, 44) + 20c
ff221524 ???????? (1b8390, fce7c000, 0, 0, ff221518, 1)
fef44990 _lwp_start (0, 0, 0, 0, 0, 0)
Truss output-
20693/20: 690.6373
stat64("/data/apache-2.2.22/xyz/htdocs/img/hcmgmt/disability_blue.gif",
0xFCE7BA18) = 0
20693/20: d=0x04B4791E i=62364 m=0100777 l=1 u=0 g=1 sz=851
20693/20: at = Jun 1 13:37:34 EDT 2012 [ 1338572254 ]
20693/20: mt = Jul 17 17:29:54 EDT 2001 [ 995405394 ]
20693/20: ct = May 30 19:56:03 EDT 2012 [ 1338422163 ]
20693/20: bsz=8192 blks=2 fs=ufs
20693/20: 690.6384 getpid() = 20693 [7534]
20693/20: 690.6386 time() = 1338572791
20693/20: 690.6388 time() = 1338572791
20693/20: 690.6416 getpid() = 20693 [7534]
20693/20: 690.6418
open("/data/apache-2.2.22/xyz/htdocs/img/hcmgmt/disability_blue.gif",
O_RDONLY|O_LARGEFILE) = 28
20693/20: 690.6424 fcntl(28, F_GETFD, 0x00000000) = 0
20693/20: 690.6425 fcntl(28, F_SETFD, 0x00000001) = 0
20693/20: 690.6428 mmap64(0x00000000, 851, PROT_READ, MAP_SHARED, 28, 0)
= 0xFEB50000
20693/20: 690.6432 munmap(0xFEB50000, 851) = 0
20693/20: 690.6434 writev(27, 0xFCE7B410, 1) = 1119
20693/20: iov_base = 0x00548DD8 iov_len = 1119
20693/20: 1703\0\0EE0402B1F191 .E685FCB593\tE5C2B88C18 zDECA j + _ t ! YA0
20693/20: (E9D7 @C3B0BE05FE8AE09E .E7 C L1D YCB9F ZBE\0 2B7 'DB - $ R87 u
20693/20: AE ] >07C9 _E1D1859FE7 W 7879E ,AA18 `E1E8 gF3BA9D d I ' `01BE18
20693/20: F8E9 F14 t _ # U859EA0B9 S K lA2C7\nA81F %17 $ s ,859D PBA 8711
20693/20: D38F vC3 I\r9AEC\n . }1CBBFA9A 305 rDE88E0A9 Z pCB A cB2 :DDDD V
20693/20: ^7FA7 xD4 4 [ vA205D8D8 e89C1868B & @ABC88C \19\b - f v cFA\0EC
20693/20: EED1 p cC8BA _80AC050F0F v p oA597 ? ? C $A982 3 nD6C519 @ I84D5
20693/20: 5 5 p90CD - w1EA1 B81DA m v10 "C7 .C41703\003 g @ a 1A28F f TA2
20693/20: xB4 >89 r uC7AC0394 !A5 i Z TB0BB8D01 D7F +F3 bC8\nF9 A88 H BEE
20693/20: 02B3 k16 (191419 QE7CDE4A5 BF1 X -05 &DDAF < T "A0 eBC86 v 1 nE2
20693/20: CC97EF B91F6 6 Q yC9 $ 3 U82 a94EC 0 : .E107 <F3 L !B5 } \15FCEE
20693/20: A581B9D5 CE10EA7E3 N JACDBCD91 OE4 _ o97 .B88A8983 VD8B69E ?848A
20693/20: B2 fF7B9AFCAB2 BB2D7 [ y FA3F28C ZE3 L -05 N $BBAE90 -1DF7 nEF i
20693/20: D7D9 ' y O b02\0C9F6\bB8 a031313 $ <968C k9CBD83 k d\0 sFF1BA912
20693/20: C113DC B #0E k k\0C987E4 LC0F3 _ I1CCDC4DD A0E v03E4E4 k18C0 mB7
20693/20: BEE\b8AF5 59DFA 1AA96 l tE5 <BE\b8ABFB1 4B6B3 D1F95 R 4 !9AD9D1
20693/20: F0 AEDD61E -B0 ! H9BC3F4 s N -83 Z \ 9C5F79DC7 m94BA Z m 1 mEE
20693/20: _F2 l KBD O0F G 4C7 r `04 ^90B1 e03 < # %9513C6 , O `F9 9BF y81
20693/20: F4 wD6 y90 x d b8F 8 y YFC %B6C6B893819DEAD1E7 E J +8C w nE4CB ?
20693/20: DACAB5BB899487E6 f OB58C .88ABC681 hA0 ,9E . 4 %B7 C3CA ; 'C0 l
20693/20: E6F2 @ + f s7FFBD791AF c o9E\bD1 ~ +C0 KEA818A92 uBAD3D1 XEA8C "
20693/20: 11B805 , 4A0\fEC ^ yF50F U )BFB707 r WCE {EC8A E96901D05 E u\t h
20693/20: 9F jF9FF 1AD8F01 jB4F3B117 } RD7A3C0BDF31003E1 > w uCF 9D87 % j
20693/20: cA7 $9D yC2 5FC95DA ? sA0CDAD C85 1 >D5DA = > sFCD6 S BB9F580FF
20693/20: 83FAE3CEAD r01CDB01F m\rF3\f : ' T1FC2B5D7A9EBF31395CFEC100EA7 L
20693/20: '96E3BC86 aBDDB [CAF2 z 8A4C599ABEFE2 ] 9AB99D d B p s0398 h1F
20693/20: RA9 VFFC6BCD2E0D71B07 % ] Q z180196\n \8B y T96FFCC06F191A9E7 u
20693/20: 9806 a1594E1981B l 495 ) f GA9E9 V ND11CFFD78F17EB\vB78E90BA :DE
20693/20: \b0E 4 yC9E7C291 / )8F01A5 R8D05E0BC0FC9E2 | s18AAD4 78A U Z hB0
20693/20: 1C 5AE8D Q19E001 vD5DE BD x W86 @88 = 8 e8F8D83C0D31998 r _ 'F6
20693/20: 84 z HAED003D6C2 ' Q13C5 v p17 ?A0A8 _B3C296 KB6AAD49FC8 dC2DC >
20693/20: AE =CC GCD12\n\nB1B6F7 dA6C4 YF4 Q c lE5CDA38B 4 ,\bDEC77F YF0\t
20693/20: C2 %97C9B992 O gB3 eC2 cF1 WDC1F j f 4 hBDF087CFDEE5ADE8A5 0 6 ~
20693/20: + .96EB g !92 FB2F795 u "F2C9BAA50E03\v @ I1BA7D911 C pBE c\0 g
20693/20: AD $D9ECD88715CD e9B05 :BCECA8F012 V ( ^D2 n $AD181889 y18D8D5
20693/20: 690.6832 Incurred fault #6, FLTBOUNDS %pc = 0x0002E26C
20693/20: siginfo: SIGSEGV SEGV_MAPERR addr=0x006E0000
20693/20: 690.6835 Received signal #11, SIGSEGV [caught]
20693/20: siginfo: SIGSEGV SEGV_MAPERR addr=0x006E0000
20693/20: 690.6837 lwp_sigmask(SIG_SETMASK, 0xFFBE6407, 0x0000FFF7) =
0xFFBFFEFF [0x0000FFFF]
20693/20: 690.6839 chdir("/data1/apache-cores") = 0
20693/20: 690.6843 sigaction(SIGSEGV, 0xFCE7B628, 0xFCE7B6C8) = 0
20693/20: new: hand = 0x00000000 mask = 0 0 0 0 flags = 0x0000
20693/20: old: hand = 0x00000000 mask = 0 0 0 0 flags = 0x0000
20693/20: 690.6849 getpid() = 20693 [7534]
20693/20: 690.6850 getpid() = 20693 [7534]
20693/20: 690.6852 kill(20693, SIGSEGV) = 0
20693/20: 690.6854 setcontext(0xFCE7B628)
This looks like bug in Apache.
Thanks
Maulik
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #6 from Stefan Fritsch <sf...@sfritsch.de> ---
(In reply to comment #4)
> Please let me know any command that i can run on mdb which provide more
> information to you.
Sorry, I know nothing about mdb.
But your log entries are in fact weird. They could mean that there is some
memory corruption earlier on and the segfault is happening later at an
unrelated point in the code.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #4 from Maulik <ma...@gmail.com> ---
Thanks Stefan.
I have mdb installed on Solaris Sparc and logformat for 2.2.22 that i have used
is -
LogFormat "%h %l %{sm_user}i %t \"%r\" %>s %b" common
==> we are using SSO and getting sso user id using sm_user variable.
One another thing which i am not sure how relevant is -
in this server there are lots of weird entries present in first column of
access log which should display client IP as per log format.
e.g.
.NET CLR 3.0.04506.648; .NET CLR 3.5.21022) - 111111111 [03/Jun/2012:04:31:26
-0400] "GET /abc/css/gestyle.css HTTP/1.1" 200 9367
*/* - 111111111 [03/Jun/2012:04:41:30 -0400] "GET /javascript/logout.js
HTTP/1.1" 200 1078
Please let me know any command that i can run on mdb which provide more
information to you.
Thanks
Maulik
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #8 from Maulik <ma...@gmail.com> ---
I tried to attach httpd process in mdb and run the commands -
bash-3.00# mdb /data/apache-2.2.22/bin/httpd
> :A 13483
Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ]
> ::sysbp _exit
> ::run
mdb: stop on SIGILL
mdb: target stopped at:
libcrypto.so.1.0.0`_sparcv9_fmadd_probe+0xc: 0x81b80440
mdb: You've got symbols!
But I am getting error -
libcrypto.so.1.0.0`_sparcv9_fmadd_probe+0xc: 0x81b80440
Can anyone tell what's the issue? This is really frustrating. If anyone can
help that will be great. Is it Apache bug for Solaris 10?
Thanks
Maulik
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_escape_logitem() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
Jeff Trawick <tr...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Segmentation fault in |Segmentation fault in
|ap_mpm_pod_check() method |ap_escape_logitem() method
--- Comment #11 from Jeff Trawick <tr...@apache.org> ---
A common misconception when attempting to analyze child process crashes is
blaming ap_mpm_pod_check() or its call of read().
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_escape_logitem() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
Jeff Trawick <tr...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #12 from Jeff Trawick <tr...@apache.org> ---
(In reply to comment #10)
> My problem got resolved. It turned out to be one of the modules that we have
> written causing the problem. I have disabled that module and that did the
> trick. Actully, the same module was running fine with 2.2.9 so that made me
> curious what got changed that causing the issue.
> Remember, i had also mentioned that i had lots of wiered entries in the logs
> in the first column (where it supposed to show remote client IP?). So when i
> checked the mod_log_config.c, it seems one option had been added (-k) which
> was not there in 2.2.9 and some how that's causing conflict with our custom
> module.
> By the way, custome module was changing the remote ip to one we are passing
> through config for security reason. But we have used work around and disable
> that plug-in.
Maybe a conn_rec was created by the custom module and allocated from the wrong
pool?
At any rate this is apparently not an httpd bug.
>
> Thanks Stefan for acknowledging that "wiered log entries could lead to
> Segmentation error".
>
> I think we could have resolved the issue by increasing length for below
> mentioned two parameters, but that needs rebuilding of Apache -
>
> LimitRequestFieldSize
> LimitRequestLine
>
> Hope, that helps to some one who are facing such issues given the similar
> situation!
Unclear. The problem doesn't occur without the custom code, and others
probably won't have that custom code.
If you find out the root cause (exactly what in the custom module led to the
problem), update the bug in case it can help others.
>
> Thanks
> Maulik
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 53329] Segmentation fault in ap_mpm_pod_check() method
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53329
--- Comment #3 from Maulik <ma...@gmail.com> ---
Thanks Stefan.
I have mdb installed on Solaris Sparc and logformat for 2.2.22 that i have used
is -
LogFormat "%h %l %{sm_user}i %t \"%r\" %>s %b" common
==> we are using SSO and getting sso user id using sm_user variable.
One another thing which i am not sure how relevant is -
in this server there are lots of weird entries present in first column of
access log which should display client IP as per log format.
e.g.
.NET CLR 3.0.04506.648; .NET CLR 3.5.21022) - 111111111 [03/Jun/2012:04:31:26
-0400] "GET /abc/css/gestyle.css HTTP/1.1" 200 9367
*/* - 111111111 [03/Jun/2012:04:41:30 -0400] "GET /javascript/logout.js
HTTP/1.1" 200 1078
Please let me know any command that i can run on mdb which provide more
information to you.
Thanks
Maulik
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org