Closed andresriancho closed 10 years ago
Github doesn't support uploading of the /tmp/53db718b-1a95-cd46-7b353fd9-1a970975.dmp
, but I'll happly email you this information.
I get the buffer overflow every time I run against w3af.org or www.clarin.com.ar
Other sites, like gmail.com succeed.
Nera and I are pretty sure this is related to #3 and #4. We need to move away from UString to StringImpl, as UString seems to trigger memory bug in JGlobalData where they allocate a buffer of hardcoded size. Stay tuned...
can u try this branch and see on 64 bit platform? https://github.com/neraliu/tpjs/tree/rhel64-64-devel
:+1:
yeah. the new implementation is more "friendly" hack to the webkit, but there is performance hit as compared with the 32 bit version. anyway, lot of way to optimize the code.
hopefully it is more stable to the 32 bit version.
FYI, this bug seems to be triggered via the undocumented object serialization inside Webkit's JavaScriptCore (the version which phantomjs is based on) that their serialization has assumed the underlying UString (or related classes) need to be smaller than certain size. Thus for 64 bit, class size is larger, it hits the size limit quickly.
@neraliu would have more details. And after several trial and error, it appears to us that the only bulletproof fix on this is not to touch their class structure.
yes. with this issue, we finally think of a new way to hack JavaScriptCore, and this hack can be ported into other javascript engine easily (not yet proven, but with greater chance)