Re: Issue 487420 in chromium: dEQP: Memory corruption running gles3.functional on a single context - deqp::gls::AttributePack::~AttributePack()+0x4a

4 views
Skip to first unread message

chro...@googlecode.com

unread,
May 13, 2015, 12:11:33 AM5/13/15
to chromi...@chromium.org

Comment #6 on issue 487420 by i...@chromium.org: dEQP: Memory corruption
running gles3.functional on a single context -
deqp::gls::AttributePack::~AttributePack()+0x4a
https://code.google.com/p/chromium/issues/detail?id=487420

I tried to make a list of tests not to run in
hasty/--deqp-runmode=txt-caselist mode, but each time I add failing tests
to expectations more fail later. There is a fundamental problem with
leakage.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

chro...@googlecode.com

unread,
May 13, 2015, 7:30:31 PM5/13/15
to chromi...@chromium.org

Comment #7 on issue 487420 by i...@chromium.org: dEQP: Memory corruption
running gles3.functional on a single context -
deqp::gls::AttributePack::~AttributePack()+0x4a
https://code.google.com/p/chromium/issues/detail?id=487420

I briefly discussed with Naveen what the cause of this could be, as Android
runs the tests all at once. Obviously ChromeOS does runtime checking to
detect the memory corruption and Android most likely not. But more
importantly I changed the ordering of the tests. For consistency the
ChromeOS testing framework orders the dEQP tests alphabetically before
execution, and this change of ordering probably exposes otherwise unknown
issues.

chro...@googlecode.com

unread,
May 13, 2015, 9:10:07 PM5/13/15
to chromi...@chromium.org

Comment #8 on issue 487420 by i...@chromium.org: dEQP: Memory corruption
running gles3.functional on a single context -
deqp::gls::AttributePack::~AttributePack()+0x4a
https://code.google.com/p/chromium/issues/detail?id=487420

Even with the original sorting order and running
bin/autotest tests/graphics_dEQP/control.gles2.functional

then dEQP-GLES2.functional.draw.random.0 reliably kills the run with a
memory corruption after GL_INVALID_OPERATIONs starting in
dEQP-GLES2.functional.draw.draw_arrays.first.first_0.

Ran standalone the test passes in every single log that I have collected.
Reply all
Reply to author
Forward
0 new messages