Can you clarify what release version you are using?  If you are building from 
trunk, please give the SVN revision number.

You are building from source with BUILDTYPE=Debug I assume.  Can you provide 
more context about how you found this?

Thanks!

Hi,

I should have mentioned that at the first message but I use PSOL and not 
modpagespeed itself. I was using Debug build type when assert have happened.

I can't tell exact version, but it was checkout of latest beta couple of month 
old. However I believe that current latest beta source code still have the bug.

Here is the backtrace:

#0  base::debug::BreakDebugger () at
third_party/chromium/src/base/debug/debugger_posix.cc:181
181    }
(gdb) backtrace
#0  base::debug::BreakDebugger () at
third_party/chromium/src/base/debug/debugger_posix.cc:181
#1  0x080b6e07 in logging::LogMessage::~LogMessage (this=0xad1fe78c,
__in_chrg=<optimised out>) at third_party/chromium/src/base/logging.cc:628
#2  0x08112408 in net_instaweb::Resource::ContentsHash (this=0x8e5b6df0) at
net/instaweb/rewriter/resource.cc:60
#3  0x08112601 in net_instaweb::Resource::FillInPartitionInputInfo
(this=0x8e5b6df0,
include_content_hash=net_instaweb::Resource::kIncludeInputHash, input=
    0x8ed0d5d0) at net/instaweb/rewriter/resource.cc:79
#4  0x081124cc in net_instaweb::Resource::AddInputInfoToPartition
(this=0x8e5b6df0,
suggest_include_content_hash=net_instaweb::Resource::kIncludeInputHash,
    index=0, partition=0x8ed139f8) at net/instaweb/rewriter/resource.cc:69
#5  0x083f1339 in net_instaweb::SingleRewriteContext::Partition
(this=0x8e5cef10, partitions=0x8e8608c8, outputs=0x8e5cef3c)
    at net/instaweb/rewriter/single_rewrite_context.cc:55
#6  0x083e8c84 in net_instaweb::RewriteContext::PartitionAsync
(this=0x8e5cef10, partitions=0x8e8608c8, outputs=0x8e5cef3c)
    at net/instaweb/rewriter/rewrite_context.cc:1633
#7  0x083e69ae in net_instaweb::RewriteContext::StartRewriteForHtml
(this=0x8e5cef10) at net/instaweb/rewriter/rewrite_context.cc:1228
#8  0x083e684d in net_instaweb::RewriteContext::Activate (this=0x8e5cef10)
at net/instaweb/rewriter/rewrite_context.cc:1219
#9  0x083e6446 in net_instaweb::RewriteContext::ResourceFetchDone
(this=0x8e5cef10, success=true, resource=..., slot_index=0)
    at net/instaweb/rewriter/rewrite_context.cc:1179
#10 0x083eff85 in
net_instaweb::MemberFunction3<net_instaweb::RewriteContext, bool,
net_instaweb::RefCountedPtr<net_instaweb::Resource>, int>::Run (
    this=0xaa0c7e68) at ./net/instaweb/util/public/function.h:232
#11 0x08172e6f in net_instaweb::Function::CallRun (this=0xaa0c7e68) at
net/instaweb/util/function.cc:51
#12 0x0818290f in net_instaweb::QueuedWorkerPool::Run (this=0x98c3490,
sequence=0x88bff058, worker=0xb0982f08) at
net/instaweb/util/queued_worker_pool.cc:133
#13 0x08188817 in
net_instaweb::MemberFunction2<net_instaweb::QueuedWorkerPool,
net_instaweb::QueuedWorkerPool::Sequence*,
net_instaweb::QueuedWorker*>::Run (this=0xa9c5b3a8) at 
./net/instaweb/util/public/function.h:207
#14 0x08172e6f in net_instaweb::Function::CallRun (this=0xa9c5b3a8) at 
net/instaweb/util/function.cc:51
#15 0x08196ca8 in net_instaweb::Worker::WorkThread::Run (this=0xb1015668)
at net/instaweb/util/worker.cc:84
#16 0x081a3b49 in net_instaweb::PthreadThreadImpl::InvokeRun
(self_ptr=0xaec1af98) at net/instaweb/util/pthread_thread_system.cc:84
#17 0xb7296d4c in start_thread (arg=0xad1ffb40) at pthread_create.c:308
#18 0xb71d4d3e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

There were no other threads running pagespeed code except of idle workers. 
Assert have happened only once so far.

DCHECK was called for Resource::IsValidAndCacheable(). The same function was 
called before Resource::ContentsHash() in Resource::FillInPartitionInfo(). 
IsValidAndCacheable results in HTTPCache::IsCurrentlyValid() which have check 
headers.CacheExpirationTimeMs() > now_ms at http_cache.c:113. I think it's a 
problem, since now_ms is updated in HTTPCache::IsAlreadyExpired() (on every 
IsValidAndCacheable() invocation). Probably response headers reached expiration 
time between two calls to HTTPCache::IsCurrentlyValid().

If it does matter I use GoogleTimer and not AprTimer.

Thanks for the report, your explanation makes sense, it could be that the 
resource is expiring between the two calls. Note, this is a DCHECK() which 
means it will only fail in debug build, so you will not have to worry about 
this failing in a production build.

Let me know if you can get this to consistently fail. Otherwise, I'll try 
re-jiggering the code a bit assuming the problem is a expiring between two 
calls.

I ran into this problem myself when working on the memcached interface and it 
turns out it was due to cache implementation stack.

Can you describe your cache implementation stack?

The resolution to the problem can be seen here: 
http://code.google.com/p/modpagespeed/source/detail?r=2124 and in particular 
this code area:

http://code.google.com/p/modpagespeed/source/browse/trunk/src/net/instaweb/util/
async_cache.cc#104

The bug was that we were writing the resource contents into a threaded cache, 
and mutating the value on the Write while simultaneously reading the resource.  
That race was resolved by doing the mutation prior to handling control to the 
threaded cache.

I was using WriteThroughCache with ThreadsafeCache+MemCache and FileCache. 
Recently I've added AsyncCache on top of existing cache and have not seen the 
issue since that time, I think it is ok now.

However I think it's not a good idea to use current time in DCHECK which is 
supposed to be called two times in a row. It probably should be changed because 
someone else can have the same problem with different cache implementation 
stack. 

Thank you for your time, I believe the issue is resolved for me. I'll let you 
know if it happens again.

BTW AprMemCache and FileCache do not need to be wrapped with ThreadSafeCache.  
They are both already threadsafe in operation (not in setup of course).  That 
assumes that your implementation of Variable is threadsafe.  In mod_pagespeed, 
we mostly access AprMemCache from a single thread (via AsyncCache) but this is 
not exclusive, and the underlying apr_memcache.c is thread-safe (or at least 
attempts to be).

May I ask what you are working on with PSOL?

Yes, I'm aware that FileCache doesn't need to be wrapped with ThreadSafeCache - 
thanks to good comments :)

However I don't use (yet) AprMemCache). I work on integrating PSOL into 
in-house proxy server. It uses event model and I had want to be sure that all 
cache operations are performed asynchronously (i.e. load response from 
FileCache). That's why I've used AsyncCache.