Hello, we get sometimes a Segmentation Fault on our Linux Webserver. a Debug with gdb give us this: Core was generated by `/usr/sbin/apache2 -k start'. Program terminated with signal SIGSEGV, Segmentation fault. #0 find_block_of_size (size=size@entry=48, rmm=0x7f2b6b497148) at /build/buildd/apr-util-1.5.3/misc/apr_rmm.c:106 106 if (blk->size == size) The bug comes sometimes often and someimes there is nothing.
The Linux is a Ubuntu Server 14.04.3 LTS, and is running on VMWARE.
*** Bug 58482 has been marked as a duplicate of this bug. ***
Could you please provide the full gdb backtrace with "thread apply all bt"?
Thread 1 (Thread 0x7f2b6b4f3780 (LWP 6508)): #0 find_block_of_size (size=size@entry=48, rmm=0x7f2b6b497148) at /build/buildd/apr-util-1.5.3/misc/apr_rmm.c:106 blk = 0x7574d268c0879c3d next = 8463481122625367093 best = 185896 bestsize = 3185506394507793239 #1 0x00007f2b6abfe2f8 in apr_rmm_calloc (rmm=0x7f2b6b497148, reqsize=<optimized out>) at /build/buildd/apr-util-1.5.3/misc/apr_rmm.c:342 size = 48 this = <optimized out> #2 0x00007f2b64bcf0ba in util_ald_alloc (cache=0x7f2b6b387c88, size=48) at util_ldap_cache_mgr.c:105 block = 8463481122625367093 #3 0x00007f2b64bcf85f in util_ald_cache_insert (cache=0x7f2b6b387c88, payload=payload@entry=0x7fff6e2a1ea0) at util_ldap_cache_mgr.c:470 hashval = <optimized out> tmp_payload = <optimized out> node = <optimized out> #4 0x00007f2b64bcc047 in uldap_cache_checkuserid (r=<optimized out>, ldc=0x7f2b6b48d0a0, url=<optimized out>, basedn=<optimized out>, scope=<optimized out>, attrs=0x7f2b6b40a410, filter=0x7fff6e2a1fc0 "(&(objectClass=*)(sAMAccountName=moritz.jirka))", bindpw=0x7f2b6b3672c5 "929567", binddn=0x7fff6e2a1f60, retvals=0x7f2b6b3672f0) at util_ldap.c:1846 vals = 0x7f2b6b367368 numvals = 2 result = <optimized out> res = 0x7f2b6d2d2af0 entry = 0x7f2b6d2d2af0 dn = <optimized out> count = <optimized out> failures = <optimized out> curl = 0x7f2b6b38a1a8 curnode = { url = 0x7f2b6b40a370 "ldap://de++++++++/ou=benutzer,dc=e+++,dc=local?sAMAccountName?sub?(objectClass=*)", search_cache = 0x7f2b6a9c45e7 <apr_pmemdup+39>, compare_cache = 0x7f2b8fba80be, dn_compare_cache = 0x7f2b6b36a0a0} search_nodep = 0x0 the_search_node = { username = 0x7fff6e2a1fc0 "(&(objectClass=*)(sAMAccountName=moritz.jirka))", dn = 0x7f2b6b367310 "CN=Moritz Jirka,OU=SozA_WS_2015,OU=WS2015,OU=Studenten,OU=Benutzer,DC=efhd,DC=local", bindpw = 0x7f2b6b3672c5 "929567", lastbind = 1444059799669958, vals = 0x7f2b6b367368, numvals = 2} curtime = <optimized out> st = <optimized out> #5 0x00007f2b68f4d3ed in authn_ldap_check_password (r=0x7f2b6b36a0a0, user=0x7f2b6b3672d0 "moritz.jirka", password=0x7f2b6b3672c5 "929567") at mod_authnz_ldap.c:528 filtbuf = "(&(objectClass=*)(sAMAccountName=moritz.jirka))\000\252r\177=\355\231\070\314M(g\342\264\257\342\004\305\316r\315\030\357ޒ\300F\311\374\022zk\350\301\303\177\356\n+5~\330\034\353\003\067\210\353\274K\326\346\032\363,\v\336`\021!w\001\350=T3c\340ʙ\f\233\342\202d_S\226\361)\036\302Df\020\024\331\031$iD\036C9\316 Dڿ\236\204\246u\203xY\233A\201]\002tg\235Ӗ4\310z\364Zw\005\262\246\364+4\326(\301M\347%!H\372\001\350\\\276pb\265^)\364\314\331$7Y\307\066XZ\325>q"... sec = 0x7f2b6b409b08 ldc = 0x7f2b6b48d0a0 result = 0 remote_user_attribute_set = 0 dn = 0x7f2b6b367310 "CN=Moritz Jirka,OU=SozA_WS_2015,OU=WS2015,OU=Studenten,OU=Benutzer,DC=efhd,DC=local" ---Type <return> to continue, or q <return> to quit--- #6 0x00007f2b6955b94e in authenticate_basic_user (r=0x7f2b6b36a0a0) at mod_auth_basic.c:383 provider = 0x7f2b691518d0 <authn_ldap_provider> conf = 0x7f2b6b367000 sent_user = 0x7f2b6b3672d0 "moritz.jirka" sent_pw = 0x7f2b6b3672c5 "929567" current_auth = <optimized out> realm = 0x0 digest = 0x0 auth_result = <optimized out> current_provider = 0x7f2b6b409af0 #7 0x00007f2b6b2bc250 in ap_run_check_user_id (r=0x7f2b6b36a0a0) at request.c:81 pHook = 0x7f2b6b49e088 n = 1 rv = 1431252021 #8 0x00007f2b6b2bf1e2 in ap_process_request_internal (r=r@entry=0x7f2b6b36a0a0) at request.c:273 file_req = <optimized out> access_status = <optimized out> d = <optimized out> #9 0x00007f2b6b2db6a8 in ap_process_async_request (r=r@entry=0x7f2b6b36a0a0) at http_request.c:315 access_status = -1 #10 0x00007f2b6b2db994 in ap_process_request (r=r@entry=0x7f2b6b36a0a0) at http_request.c:363 bb = <optimized out> b = <optimized out> c = 0x7f2b6b381290 rv = <optimized out> #11 0x00007f2b6b2d8432 in ap_process_http_sync_connection (c=0x7f2b6b381290) at http_core.c:190 r = 0x7f2b6b36a0a0 cs = 0x0 csd = 0x7f2b6b3810a0 mpm_state = 1 #12 ap_process_http_connection (c=0x7f2b6b381290) at http_core.c:231 No locals. #13 0x00007f2b6b2cf210 in ap_run_process_connection (c=0x7f2b6b381290) at connection.c:41 pHook = 0x7f2b6b49de10 n = 0 rv = 1431252021 #14 0x00007f2b6b2cf5f8 in ap_process_connection (c=c@entry=0x7f2b6b381290, csd=<optimized out>) at connection.c:202 rc = <optimized out> #15 0x00007f2b647bb767 in child_main (child_num_arg=child_num_arg@entry=17) at prefork.c:704 current_conn = 0x7f2b6b381290 csd = 0x7f2b6b3810a0 thd = 0x7f2b6b3830a0 osthd = 139824460674944 ptrans = 0x7f2b6b381028 allocator = 0x7f2b6d2d22e0 status = <optimized out> i = <optimized out> lr = <optimized out> pollset = 0x7f2b6b383158 sbh = 0x7f2b6b383150 bucket_alloc = 0x7f2b6b37d028 last_poll_idx = 1 lockfile = <optimized out> #16 0x00007f2b647bb9a6 in make_child (s=0x7f2b6b4c1de0, slot=17) at prefork.c:800 pid = 0 #17 0x00007f2b647bc60e in perform_idle_server_maintenance (p=<optimized out>) at prefork.c:902 i = <optimized out> idle_count = <optimized out> ws = <optimized out> free_length = <optimized out> free_slots = {14, 17, 18, 19, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 0 <repeats 16 times>} last_non_dead = <optimized out> total_non_dead = <optimized out> #18 prefork_run (_pconf=<optimized out>, plog=<optimized out>, s=<optimized out>) at prefork.c:1090 status = 0 pid = {pid = -1, in = 0x7f2b6b2e6608, out = 0xa, err = 0x7f2b6a9c4ff6 <find_entry+134>} child_slot = <optimized out> exitwhy = APR_PROC_EXIT processed_status = <optimized out> index = <optimized out> remaining_children_to_start = 0 rv = <optimized out> #19 0x00007f2b6b2ac8ae in ap_run_mpm (pconf=0x7f2b6b4f9028, plog=0x7f2b6b4c7028, s=0x7f2b6b4c1de0) at mpm_common.c:96 pHook = 0x7f2b6b49e268 n = 0 rv = 1431252021 #20 0x00007f2b6b2a6046 in main (argc=3, argv=0x7fff6e2a4638) at main.c:777 c = 0 '\000' showcompile = 0 showdirectives = 0 confname = 0x7f2b6b2e5bc7 "apache2.conf" def_server_root = 0x7f2b6b2e5bba "/etc/apache2" temp_error_log = 0x0 error = <optimized out> process = 0x7f2b6b4fb118 pconf = 0x7f2b6b4f9028 plog = 0x7f2b6b4c7028 ptemp = 0x7f2b6b4c3028 pcommands = 0x7f2b6b4d1028 opt = 0x7f2b6b4d1118 rv = <optimized out> mod = 0x7f2b6b507160 <ap_prelinked_modules+64> opt_arg = 0x7f2b6b4fb028 "(\360Ok+\177" signal_server = <optimized out>
Can you please execute the following commands in gdb: thread 1 frame 0 print *rmm
The Password for the User moritz.jirka is only his Matrickel numer, there are no special characters only 6 numbers. Here are the output of the commands. Core was generated by `/usr/sbin/apache2 -k start'. Program terminated with signal SIGSEGV, Segmentation fault. #0 find_block_of_size (size=size@entry=48, rmm=0x7f2b6b497148) at /build/buildd/apr-util-1.5.3/misc/apr_rmm.c:106 106 if (blk->size == size) (gdb) thread 1 [Switching to thread 1 (Thread 0x7f2b6b4f3780 (LWP 6508))] #0 find_block_of_size (size=size@entry=48, rmm=0x7f2b6b497148) at /build/buildd/apr-util-1.5.3/misc/apr_rmm.c:106 106 if (blk->size == size) (gdb) frame 0 #0 find_block_of_size (size=size@entry=48, rmm=0x7f2b6b497148) at /build/buildd/apr-util-1.5.3/misc/apr_rmm.c:106 106 if (blk->size == size) (gdb) print *rmm $1 = {p = 0x7f2b6b497028, base = 0x7f2b6b387008, size = 500000, lock = {type = apr_anylock_none, lock = {pm = 0x0, tm = 0x0, rw = 0x0}}} (gdb)
Thanks. Please also execute the following commands in addition: print blk print next print *rmm->base
(gdb) print blk $1 = (struct rmm_block_t *) 0x7574d268c0879c3d (gdb) print next $2 = 8463481122625367093 (gdb) print *rmm->base $3 = {abssize = 500000, firstused = 24, firstfree = 185896} (gdb)
(In reply to Patrick Baltz from comment #8) > (gdb) print blk > $1 = (struct rmm_block_t *) 0x7574d268c0879c3d > (gdb) print next > $2 = 8463481122625367093 > (gdb) print *rmm->base > $3 = {abssize = 500000, firstused = 24, firstfree = 185896} > (gdb) Looks like the rmm internal structures got corrupted somehow (next is far too large), but currently I have no idea how this could have happened.
*** This bug has been marked as a duplicate of bug 60296 ***