-
Notifications
You must be signed in to change notification settings - Fork 361
incomplete javascript downloading #371
Comments
Testing with telnet:
This cuts off partway through even on a freshly restarted ngx_pagespeed. |
The
|
The testing above was with Release, but it also happens with Debug. Error log:
|
I would like to test with the 1.5.27.2 binaries, but they don't support CentOS. |
This seemed like it might have been caused by 9c09f92, so I reverted that to test, but the problem persists. |
bisecting |
bad even back to commit e079640 |
Going back before then is hard because we depend on a different version of psol. |
I've switched from 8196 byte buffers in the buffer chain to 256 byte ones to make it easier to see what's going on. In telnet I still see us cutting off at the same place, after the "@return {boolean}". Interestingly, this isn't on a chain link boundary, though it is close to one. I see the previous link ending with The chain we're creating has all the links it should, and I see them all dumped to the log looking correct. With 256 byte buffers it fails partway through buffer 191 of 207. |
I think the problem is that |
Calling |
Released in 1.5.27.3 |
I've prepared a CentOS 5 VM running 1.5.27.3-rc1 as part of preparing the next release. When I run the system tests I get:
This is with wget 1.14 (CentOS ships with 1.11, which is too old for the test.)
Looking in /tmp/mod_pagespeed_test.jefftk/fetched_directory/ I see both
js_defer_debug.fxi6kLpaRF.js
andjs_defer_debug.fxi6kLpaRF.js.1
. Which makes sense: wget downloads a page that references js_defer_debug... recursively giving us the first one, and the hang is when it's getting the second one. But the second one doesn't download completely. It's 48902 bytes instead of 53109.The text was updated successfully, but these errors were encountered: