Note that this failure is visual-dependent.  I reproduce failure with 123 or 143 on both the good and bad commits cited on my ivb system, but not 139, for example.  Can you reproduce the problem with 123 on the bad commit currently?

Also, I note that you're not passing -s to your test arguments.  If you're missing that in your test harness, it means you're repeating a set of tests for every test invocation.

You also probably want to use -minFmt instead of a specific -D argument, which should be more resilient to changes in the list of visuals.

(In reply to comment #1)
> Note that this failure is visual-dependent.  I reproduce failure with 123 or
> 143 on both the good and bad commits cited on my ivb system, but not 139, for
> example.  Can you reproduce the problem with 123 on the bad commit currently?

Is it better to list the visual property like following, which may have more accurate description
"24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow"

> 
> Also, I note that you're not passing -s to your test arguments.  If you're
> missing that in your test harness, it means you're repeating a set of tests for
> every test invocation.

Just FYI, latest Oglconform has its '-s' meaning reverted

> 
> You also probably want to use -minFmt instead of a specific -D argument, which
> should be more resilient to changes in the list of visuals.

We're now using different method to work around this, actually we're always trying to find a visual has property like "24 tc  0  32  0 r  y .   8  8  8  8 .  .  0 24  8 16 16 16 16  0 0 Slow", since visual numbers seem changing by some condition. By doing this, it will be easier for us to compare results across different platforms, and different versions.

It appears that the 8 passing FBConfigs are single-buffered, while the 24 failing FBConfigs are double-buffered.

Basically, it looks like we're not flushing out changes to the front buffer at the necessary time.

Running this test in Valgrind produces some interesting data:

==9385== Invalid read of size 8
==9385==    at 0x73F4F4E: dri2FlushFrontBuffer (dri2_glx.c:608)
==9385==    by 0x86BEB9C: intel_flush_front (intel_context.c:222)
==9385==    by 0x86BF166: intel_glFlush (intel_context.c:466)
==9385==    by 0x8A3D401: _mesa_flush (context.c:1671)
==9385==    by 0x8A3CE35: _mesa_make_current (context.c:1448)
==9385==    by 0x86BFE9A: intelUnbindContext (intel_context.c:756)
==9385==    by 0x8762939: driUnbindContext (dri_util.c:393)
==9385==    by 0x73F4340: dri2_unbind_context (dri2_glx.c:177)
==9385==    by 0x73BD924: MakeContextCurrent (glxcurrent.c:255)
==9385==    by 0x157FED6: Context::make_current(Drawable_ const&) const (windowing.cpp:1378)
==9385==    by 0x15B667E: (anonymous namespace)::run_schedule(Display_ const&, boost::shared_ptr<FbConfig>, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<driverRec*, std::allocator<driverRec*> > const&, std::vector<boost::shared_ptr<PrePostAction>, std::allocator<boost::shared_ptr<PrePostAction> > > const&, std::vector<boost::shared_ptr<PrePostTestAction>, std::allocator<boost::shared_ptr<PrePostTestAction> > > const&, std::vector<boost::shared_ptr<PrePostTestcaseAction>, std::allocator<boost::shared_ptr<PrePostTestcaseAction> > > const&) (executer.cpp:186)
==9385==    by 0x15B5FC6: ExecutionManager::execute_schedules() (executer.cpp:57)
==9385==  Address 0x727fcd8 is 24 bytes inside a block of size 208 free'd
==9385==    at 0x4C29BBE: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9385==    by 0x73F47AD: dri2DestroyDrawable (dri2_glx.c:343)
==9385==    by 0x73ED567: DestroyDRIDrawable (glx_pbuffer.c:230)
==9385==    by 0x73EDC7F: DestroyDrawable (glx_pbuffer.c:468)
==9385==    by 0x73EE58B: glXDestroyWindow (glx_pbuffer.c:938)
==9385==    by 0x157F1AA: Drawable_::~Drawable_() (windowing.cpp:1229)
==9385==    by 0x15B7F88: void boost::checked_delete<Drawable_>(Drawable_*) (checked_delete.hpp:34)
==9385==    by 0x15B83E1: boost::detail::sp_counted_impl_p<Drawable_>::dispose() (sp_counted_impl.hpp:78)
==9385==    by 0x52D1FD: boost::detail::sp_counted_base::release() (sp_counted_base_gcc_x86.hpp:145)
==9385==    by 0x52D276: boost::detail::shared_count::~shared_count() (shared_count.hpp:305)
==9385==    by 0x7EA0E3: boost::shared_ptr<Drawable_>::~shared_ptr() (shared_ptr.hpp:164)
==9385==    by 0x15B688B: (anonymous namespace)::run_schedule(Display_ const&, boost::shared_ptr<FbConfig>, std::vector<std::pair<std::string, std::string>, std::allocator<std::pair<std::string, std::string> > > const&, std::vector<driverRec*, std::allocator<driverRec*> > const&, std::vector<boost::shared_ptr<PrePostAction>, std::allocator<boost::shared_ptr<PrePostAction> > > const&, std::vector<boost::shared_ptr<PrePostTestAction>, std::allocator<boost::shared_ptr<PrePostTestAction> > > const&, std::vector<boost::shared_ptr<PrePostTestcaseAction>, std::allocator<boost::shared_ptr<PrePostTestcaseAction> > > const&) (executer.cpp:248)

In other words, it looks like we're trying to flush after we delete the buffer.  That would be worth fixing.  However, since this is not an actual regression, a conformance test, and only seems to fail with front buffer rendering (seriously! who uses that?), I'm demoting this bug.

closing as won't fix.