Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to get the following apache2.2 modules to work together mod_pagespeed, mod_spdy and WebSphere Webserver plugin on CentOS.

Once mod_pagespeed changes the path of a file the browser can't resolve that file anymore. I have a coredump but I don't really know how to read this:

gdb /usr/sbin/httpd core.881
(gdb) bt full
#0  __strrchr_sse42 () at ../sysdeps/x86_64/multiarch/strrchr.S:134
No locals.
#1  0x00007ff129b02404 in ?? () from /usr/lib64/httpd/modules/
No symbol table info available.
#2  0x00007ff1348fb8b8 in ap_run_map_to_storage (r=0x7ff1362f0698) at /usr/src/debug/httpd-2.2.15/server/request.c:69
        pHook = <value optimized out>
        n = <value optimized out>
        rv = <value optimized out>
#3  0x00007ff1348fd9c8 in ap_process_request_internal (r=0x7ff1362f0698) at /usr/src/debug/httpd-2.2.15/server/request.c:150
        file_req = 0
        access_status = <value optimized out>
#4  0x00007ff13490fa20 in ap_process_request (r=0x7ff1362f0698) at /usr/src/debug/httpd-2.2.15/modules/http/http_request.c:280
        access_status = <value optimized out>
#5  0x00007ff13490c8f8 in ap_process_http_connection (c=0x7ff1362f46b8) at /usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
        r = 0x7ff1362f0698
        csd = 0x0
#6  0x00007ff134908608 in ap_run_process_connection (c=0x7ff1362f46b8) at /usr/src/debug/httpd-2.2.15/server/connection.c:43
        pHook = <value optimized out>
        n = <value optimized out>
        rv = <value optimized out>
#7  0x00007ff1291272fb in ?? () from /usr/lib64/httpd/modules/
No symbol table info available.
#8  0x00007ff129152ccd in ?? () from /usr/lib64/httpd/modules/
No symbol table info available.
#9  0x00007ff129152ccd in ?? () from /usr/lib64/httpd/modules/
No symbol table info available.
#10 0x00007ff12914f1fb in ?? () from /usr/lib64/httpd/modules/
No symbol table info available.
#11 0x00007ff1291328f1 in ?? () from /usr/lib64/httpd/modules/
No symbol table info available.
#12 0x00007ff1331ab851 in start_thread (arg=0x7ff12735d700) at pthread_create.c:301
        __res = <value optimized out>
        pd = 0x7ff12735d700
        now = <value optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140673721685760, -6615953477917025934, 140734441252576, 140673721686464, 4, 7, 6614986543813548402, 6614960367733758322},
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <value optimized out>
        pagesize_m1 = <value optimized out>
        sp = <value optimized out>
        freesize = <value optimized out>
#13 0x00007ff132ef911d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
No locals.
share|improve this question
This coredump happens on every request? On just those that would go to WebSphere? Do you have some sample URLs and how they're changed? Are there requests in access_log and/or error_log? – dbreaux Dec 29 '12 at 22:20
sample URL: FROM localhost/NexxarUtilWeb/styles/theme.css TO localhost/NexxarUtilWeb/styles/… in error_log: mod_pagespeed @2879 Fetch complete: .../NexxarUtilWeb/styles/theme.css mod_pagespeed @2879 .../NexxarUtilWeb/styles/theme_smallWorld.css: Unlocking lock /var/cache/mod_pagespeed/ltdkSbY2EwSMgFnJRlBO.lock with cached=true, success=true child pid 2873 exit signal Segmentation fault (11), possible coredump in /home/websphere/dumps – 2Fast2BCn Jan 7 '13 at 9:44
Core dumps only occur when I enable the extend_cache of pagespeed. ModPagespeedEnableFilters extend_cache – 2Fast2BCn Jan 7 '13 at 9:55
enable or disable mod_spdy doesn't change any behaviour. mod_pagespeed with extend_cache works (no coredumps) if I disable WebSphere plugin. – 2Fast2BCn Jan 9 '13 at 7:27
My guess is mod_pagespeed expects r->filename to be set and calls strchr() on NULL. Unlike mod_proxy, the WAS plugin does not set a dummy r->filename when it is handling a non file resource. – covener Jan 9 '13 at 17:48
up vote 0 down vote accepted

we are tracking this issue at My latest response on this:

I think this might be fixed already in trunk. Would it be possible for you to build from trunk & try it out?

Specifically, special handling was added for reverse-proxies to bypass this routine. It wasn't specifically because r->filename was NULL; we were not seeing a crash, but were instead having issues with 403s. This was Issue 582.

Instructions for building from trunk: -- use the "bleeding edge" version.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.