[
https://issues.apache.org/jira/browse/TS-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096311#comment-13096311
]
B Wyatt commented on TS-941:
----------------------------
The above patch allowed us to restart a previously broken instance (it would
generate a GP fault in this function immediately after the cache was enabled)
and has run fine for ~24 hours.
I may make a pass at locating any other obvious 32bit truncations of these
off_t's
> invalid cast of off_t math to int
> ---------------------------------
>
> Key: TS-941
> URL: https://issues.apache.org/jira/browse/TS-941
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
> Affects Versions: 3.1.0
> Environment: Stock debian amd64 2.6.34.7 kernel modified to increase
> XEN domU max RAM to 96Gb
> Stock build with:
> ./configure --enable-layout=Debian --sysconfdir=/etc/trafficserver --libdir=
> /usr/lib/trafficserver --with-user=root --with-group=root --enable-debug
> --enabl
> e-static-libts CFLAGS= CXXFLAGS= --enable-wccp
> Reporter: B Wyatt
>
> iocore/CacheWrite.cc:Vol::evac_range calculates its looping values from 64bit
> off_t values but stores them in 32bit integers:
> {code:title=CacheWrite.cc#1086711:694-700}
> int
> Vol::evac_range(off_t low, off_t high, int evac_phase)
> {
> int s = offset_to_vol_offset(this, low);
> int e = offset_to_vol_offset(this, high);
> int si = dir_offset_evac_bucket(s);
> int ei = dir_offset_evac_bucket(e);
> {code}
> When Vol::start and/or the low high parameters get large enough these loop
> values become truncated and potentially negative causing a general protection
> fault as it attempts to access memory addresses below the valid range.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
