0

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/mod_pagespeed.so
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/mod_spdy.so
No symbol table info available.
#8  0x00007ff129152ccd in ?? () from /usr/lib64/httpd/modules/mod_spdy.so
No symbol table info available.
#9  0x00007ff129152ccd in ?? () from /usr/lib64/httpd/modules/mod_spdy.so
No symbol table info available.
#10 0x00007ff12914f1fb in ?? () from /usr/lib64/httpd/modules/mod_spdy.so
No symbol table info available.
#11 0x00007ff1291328f1 in ?? () from /usr/lib64/httpd/modules/mod_spdy.so
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.
2Fast2BCn
  • 305
  • 2
  • 6
  • 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** https://localhost/NexxarUtilWeb/styles/theme.css **TO** https://localhost/NexxarUtilWeb/styles/theme.css.pagespeed.ce.QYXr1n5xAN.css in error_log: `mod_pagespeed 1.2.24.1-2300 @2879 Fetch complete: .../NexxarUtilWeb/styles/theme.css mod_pagespeed 1.2.24.1-2300 @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 07 '13 at 09:44
  • Core dumps only occur when I enable the extend_cache of pagespeed. ModPagespeedEnableFilters extend_cache – 2Fast2BCn Jan 07 '13 at 09:55
  • So this doesn't occur just from starting the server, correct? Only when a request comes in to the server? And for every single request? – dbreaux Jan 07 '13 at 14:41
  • Yes one coredump for every page refresh. No dumps when starting apache. – 2Fast2BCn Jan 07 '13 at 22:09
  • To be clear, I don't know anything about pagespeed, but know a little about WebSphere. So I'm trying to isolate. This problem occurs if you have pagespeed enabled whether or not you have the WebSphere plugin enabled? Or only if both (all 3?) are enabled? – dbreaux Jan 08 '13 at 15:43
  • mod_pagespeed, mod_spdy and WebSphere Webserver plugin all work without any problems if I disable pagespeed's extend_cache if I enable pagespeed's extend_cache then each page refresh generates a coredump. – 2Fast2BCn Jan 08 '13 at 23:41
  • But does that coredump only occur when all 3 are enabled and extend_cache is enabled? Or if you disable WebSphere and mod_spdy and then enable pagespeed with extend_cache, does the problem still occur. I'm trying to determine whether it's an interaction of the 3, of 2 of them, or just pagespeed itself. – dbreaux Jan 09 '13 at 03:05
  • 1
    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 09 '13 at 07:27
  • Which version of WebSphere & plugin too, please? I haven't used this combination but am intrigued, so I've forwarded your question to some folks who might be able to comment. Also have you posted to the WebSphere forum? http://www.ibm.com/developerworks/forums/forum.jspa?forumID=266&cat=9 – dbreaux Jan 09 '13 at 17:12
  • 1
    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 09 '13 at 17:48
  • WebSphere Application Server 8.5.0.1 Web Server Plug-ins for IBM WebSphere Application Server Version 8.5.0.1 – 2Fast2BCn Jan 09 '13 at 20:44
  • @dbreaux Cross posted: [link](https://www.ibm.com/developerworks/forums/thread.jspa?threadID=468741&tstart=0) – 2Fast2BCn Jan 22 '13 at 10:17
  • @covener [link](https://code.google.com/p/modpagespeed/issues/detail?id=610) – 2Fast2BCn Jan 23 '13 at 11:26

1 Answers1

0

we are tracking this issue at http://code.google.com/p/modpagespeed/issues/detail?id=610. 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: https://developers.google.com/speed/docs/mod_pagespeed/build_from_source -- use the "bleeding edge" version.

Joshua Marantz
  • 16
  • [https://code.google.com/p/modpagespeed/issues/detail?id=610#c6](https://code.google.com/p/modpagespeed/issues/detail?id=610#c6) fixed the issue. – 2Fast2BCn Jan 24 '13 at 08:34