Yes, invalidating the cache is a major obstacle. The last incompatible change was in ATS 3.2. I should have caught that change, sorry.
On Thu, Feb 21, 2019 at 9:38 AM Leif Hedstrom <zw...@apache.org> wrote: > > > > On Feb 21, 2019, at 3:04 AM, 宋辰伟 <616955...@qq.com> wrote: > > > > Not sure here. You might need to clean up your cache ? > > Well, we can’t require a cache clean as part of a 7.1.x upgrade. In fact, > that would exclude this change from 8.x as well, and we’d have to think > carefully about it for 9.x. > > Cheers, > > — Leif > > > > > Thansk > > scw00 > > > >> 在 2019年2月21日，下午5:36，宋辰伟 <616955...@qq.com> 写道： > >> > >> Could you please fill an issue ? > >> > >> Scw00 > >> > >>> 在 2019年2月20日，下午6:43，Chou, Peter <pbc...@labs.att.com> 写道： > >>> > >>> Hi, > >>> > >>> I get an assertion fault core dump in 7.1.x HEAD from HdrHeap.cc::874. > This seems to be isolated down to commit 739d8d. > >>> What I think is happening is that the copy of the content stored in > the cache uses a different amount of space before and after this change > when doing an un-marshal. > >>> I re-created the problem by - > >>> > >>> * Run ATS 7.1.6 > >>> * Cache an object > >>> * Run ATS 7.1.x HEAD > >>> * Try to read object from cache either PURGE or GET causes the > assertion error. > >>> * Deleting cache file under var clears the problem. I assume this is > not supposed to be required for minor updates. > >>> > >>> Thanks, > >>> Peter > >> > >> > >> > >> > > > >
