Use SkNVRefCnt for a couple common types.

Use SkNVRefCnt for a couple common types.

These types are ref-counted, but don't otherwise need a vtable.
This makes them good candidates for SkNVRefCnt.

Destruction can be a little more direct, and if nothing else,
sizeof(T) will get a little smaller by dropping the vptr.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002

Committed: https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6

[mtklein_C, 2016-08-09 17:36:44]

Description was changed from

==========
Use SkNVRefCnt for SkTextBlob.

SkTextBlob is ref-counted, but doesn't otherwise need a vtable.
This makes it a good candidate to use SkNVRefCnt.

There's a bit less indirection when calling unref(), which may not matter.
If nothing else, sizeof(SkTextBlob) does get a little smaller.

BUG=skia:
==========

to

==========
Use SkNVRefCnt for SkTextBlob.

SkTextBlob is ref-counted, but doesn't otherwise need a vtable.
This makes it a good candidate to use SkNVRefCnt.

There's a bit less indirection when calling unref(), which may not matter.
If nothing else, sizeof(SkTextBlob) does get a little smaller.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002
==========

[mtklein_C, 2016-08-09 17:48:16]

Description was changed from

==========
Use SkNVRefCnt for SkTextBlob.

SkTextBlob is ref-counted, but doesn't otherwise need a vtable.
This makes it a good candidate to use SkNVRefCnt.

There's a bit less indirection when calling unref(), which may not matter.
If nothing else, sizeof(SkTextBlob) does get a little smaller.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002
==========

to

==========
Use SkNVRefCnt for a couple common types.

These types are ref-counted, but don't otherwise need a vtable.
This makes them good candidates for SkNVRefCnt.

If nothing else, sizeof(T) does get a little smaller by dropping the vptr.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002
==========

[mtklein_C, 2016-08-09 17:48:41]

Description was changed from

==========
Use SkNVRefCnt for a couple common types.

These types are ref-counted, but don't otherwise need a vtable.
This makes them good candidates for SkNVRefCnt.

If nothing else, sizeof(T) does get a little smaller by dropping the vptr.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002
==========

to

==========
Use SkNVRefCnt for a couple common types.

These types are ref-counted, but don't otherwise need a vtable.
This makes them good candidates for SkNVRefCnt.

Destruction can be a little more direct, and if nothing else,
sizeof(T) will get a little smaller by dropping the vptr.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002
==========

[mtklein_C, 2016-08-09 17:48:57]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-09 17:49:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-09 17:52:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-09 17:52:36]

Dry run: Try jobs failed on following builders:
  Build-Ubuntu-GCC-Arm64-Debug-Android-Trybot on master.client.skia.compile
(JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm...)
  Build-Ubuntu-GCC-Mips-Debug-Android-Trybot on master.client.skia.compile
(JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Mip...)

[mtklein_C, 2016-08-09 17:57:03]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-09 17:57:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-09 18:14:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-09 18:14:44]

Dry run: This issue passed the CQ dry run.

[mtklein_C, 2016-08-09 18:15:15]

mtklein@chromium.org changed reviewers:
+ reed@google.com

[mtklein_C, 2016-08-09 18:15:15]

The CQ bit was checked by mtklein@chromium.org

[commit-bot: I haz the power, 2016-08-09 18:15:29]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-09 18:16:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-09 18:16:54]

Try jobs failed on following builders:
  skia_presubmit-Trybot on master.client.skia.fyi (JOB_FAILED,
http://build.chromium.org/p/client.skia.fyi/builders/skia_presubmit-Trybot/bu...)

[reed1, 2016-08-09 18:36:59]

generalize question: changing to NVRefCnt.. does that always allow us to also
mark the class as final?

https://codereview.chromium.org/2232433002/diff/60001/include/core/SkData.h
File include/core/SkData.h (right):

https://codereview.chromium.org/2232433002/diff/60001/include/core/SkData.h#n...
include/core/SkData.h:22: class SK_API SkData : public SkNVRefCnt<SkData> {
can we mark SkData as final?

[mtklein, 2016-08-09 18:39:14]

On 2016/08/09 18:36:59, reed1 wrote:
> generalize question: changing to NVRefCnt.. does that always allow us to also
> mark the class as final?

Yep.  SkData, SkPathRef, and SkTextBlob are just like SkRect as far as final
goes: we can mark them final if we want, and it will have no effect beyond
preventing subclassing.

[reed1, 2016-08-09 18:40:11]

On 2016/08/09 18:39:14, mtklein wrote:
> On 2016/08/09 18:36:59, reed1 wrote:
> > generalize question: changing to NVRefCnt.. does that always allow us to
also
> > mark the class as final?
> 
> Yep.  SkData, SkPathRef, and SkTextBlob are just like SkRect as far as final
> goes: we can mark them final if we want, and it will have no effect beyond
> preventing subclassing.

Hmmm, seems different, in that we have a non-trivial destructor (in SkData for
example), and if we make it not be virtual, then subclassing is a risk, no?

[mtklein, 2016-08-09 18:53:28]

On 2016/08/09 18:40:11, reed1 wrote:
> On 2016/08/09 18:39:14, mtklein wrote:
> > On 2016/08/09 18:36:59, reed1 wrote:
> > > generalize question: changing to NVRefCnt.. does that always allow us to
> also
> > > mark the class as final?
> > 
> > Yep.  SkData, SkPathRef, and SkTextBlob are just like SkRect as far as final
> > goes: we can mark them final if we want, and it will have no effect beyond
> > preventing subclassing.
> 
> Hmmm, seems different, in that we have a non-trivial destructor (in SkData for
> example), and if we make it not be virtual, then subclassing is a risk, no?

Yeah, it's not safe to delete an SkData subclass through an SkData* unless
~SkData() is virtual.

Added final to each of these.

[mtklein_C, 2016-08-09 18:53:44]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-09 18:53:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[reed1, 2016-08-09 19:07:30]

lgtm

[commit-bot: I haz the power, 2016-08-09 19:17:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-09 19:17:41]

Dry run: This issue passed the CQ dry run.

[mtklein_C, 2016-08-09 19:18:30]

The CQ bit was checked by mtklein@chromium.org

[commit-bot: I haz the power, 2016-08-09 19:18:41]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-09 19:20:06]

Description was changed from

==========
Use SkNVRefCnt for a couple common types.

These types are ref-counted, but don't otherwise need a vtable.
This makes them good candidates for SkNVRefCnt.

Destruction can be a little more direct, and if nothing else,
sizeof(T) will get a little smaller by dropping the vptr.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002
==========

to

==========
Use SkNVRefCnt for a couple common types.

These types are ref-counted, but don't otherwise need a vtable.
This makes them good candidates for SkNVRefCnt.

Destruction can be a little more direct, and if nothing else,
sizeof(T) will get a little smaller by dropping the vptr.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2232433002

Committed:
https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6
==========

[commit-bot: I haz the power, 2016-08-09 19:20:09]

Committed patchset #5 (id:80001) as
https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6

[Joel.Liang, 2016-08-16 06:18:02]

On 2016/08/09 19:20:09, commit-bot: I haz the power wrote:
> Committed patchset #5 (id:80001) as
> https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6

This CL will cause "Bus error\n EXIT_CODE is 135" on Android devices.
You can run gm tests to reproduce this issue.
./platform_tools/android/bin/android_run_skia dm --config gpu --resourcePath
/sdcard/skia_resources

I have tested on Huawei Mate 8, Samsung Note 10.1 and Samsung Galaxy S5.

[mtklein, 2016-08-16 12:30:26]

On 2016/08/16 06:18:02, Joel.Liang wrote:
> On 2016/08/09 19:20:09, commit-bot: I haz the power wrote:
> > Committed patchset #5 (id:80001) as
> >
https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6
> 
> This CL will cause "Bus error\n EXIT_CODE is 135" on Android devices.
> You can run gm tests to reproduce this issue.
> ./platform_tools/android/bin/android_run_skia dm --config gpu --resourcePath
> /sdcard/skia_resources
> 
> I have tested on Huawei Mate 8, Samsung Note 10.1 and Samsung Galaxy S5.

I don't think we've seen that.  Can you post a stack trace?

[Joel.Liang, 2016-08-16 15:48:18]

On 2016/08/16 12:30:26, mtklein wrote:
> On 2016/08/16 06:18:02, Joel.Liang wrote:
> > On 2016/08/09 19:20:09, commit-bot: I haz the power wrote:
> > > Committed patchset #5 (id:80001) as
> > >
> https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6
> > 
> > This CL will cause "Bus error\n EXIT_CODE is 135" on Android devices.
> > You can run gm tests to reproduce this issue.
> > ./platform_tools/android/bin/android_run_skia dm --config gpu --resourcePath
> > /sdcard/skia_resources
> > 
> > I have tested on Huawei Mate 8, Samsung Note 10.1 and Samsung Galaxy S5.
> 
> I don't think we've seen that.  Can you post a stack trace?

6.31m elapsed, 2 active, 81 queued, 48MB RAM, 1433MB peak
	unit test  PathMeasure
	unit test  SkSharedMutexMultiThreaded
[New Thread 32072.32102]
[New Thread 32072.32116]
[New Thread 32072.32117]
[New Thread 32072.32118]
[New Thread 32072.32119]
[New Thread 32072.32120]
[New Thread 32072.32121]
[New Thread 32072.32122]
[New Thread 32072.32126]

Thread 2 "skia_launcher" received signal SIGBUS, Bus error.
[Switching to Thread 32072.32102]
compress_r11eac_blocks () at ../../../../src/opts/SkTextureCompressor_opts.h:208
208	        vst1q_u64(dst1, d1);
(gdb) bt
#0  compress_r11eac_blocks () at
../../../../src/opts/SkTextureCompressor_opts.h:208
#1  compress_a8_r11eac () at ../../../../src/opts/SkTextureCompressor_opts.h:231
#2  0xb60629a4 in CompressBufferToFormat () at
../../../../src/utils/SkTextureCompressor.cpp:125
#3  CompressBitmapToFormat () at
../../../../src/utils/SkTextureCompressor.cpp:157
#4  0xb5312038 in test_CompressCheckerboard () at
../../../../tests/TextureCompressionTest.cpp:157
#5  0xb512fb62 in run_test () at ../../../../dm/DM.cpp:1248
#6  0xb5f853c6 in operator() ()
    at
/home/joel/dev/skia/android_repo/platform_tools/android/bin/../toolchains/arm-r12b-14/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/functional:2439
#7  Loop () at ../../../../src/core/SkTaskGroup.cpp:167
#8  0xb6069f16 in thread_start () at
../../../../src/utils/SkThreadUtils_pthread.cpp:66
#9  0xb6f67668 in __pthread_start(void*) ()
   from
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
#10 0xb6f65684 in __start_thread ()
   from
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
#11 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

[mtklein, 2016-08-16 15:50:33]

On 2016/08/16 15:48:18, Joel.Liang wrote:
> On 2016/08/16 12:30:26, mtklein wrote:
> > On 2016/08/16 06:18:02, Joel.Liang wrote:
> > > On 2016/08/09 19:20:09, commit-bot: I haz the power wrote:
> > > > Committed patchset #5 (id:80001) as
> > > >
> >
https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6
> > > 
> > > This CL will cause "Bus error\n EXIT_CODE is 135" on Android devices.
> > > You can run gm tests to reproduce this issue.
> > > ./platform_tools/android/bin/android_run_skia dm --config gpu
--resourcePath
> > > /sdcard/skia_resources
> > > 
> > > I have tested on Huawei Mate 8, Samsung Note 10.1 and Samsung Galaxy S5.
> > 
> > I don't think we've seen that.  Can you post a stack trace?
> 
> 6.31m elapsed, 2 active, 81 queued, 48MB RAM, 1433MB peak
> 	unit test  PathMeasure
> 	unit test  SkSharedMutexMultiThreaded
> [New Thread 32072.32102]
> [New Thread 32072.32116]
> [New Thread 32072.32117]
> [New Thread 32072.32118]
> [New Thread 32072.32119]
> [New Thread 32072.32120]
> [New Thread 32072.32121]
> [New Thread 32072.32122]
> [New Thread 32072.32126]
> 
> Thread 2 "skia_launcher" received signal SIGBUS, Bus error.
> [Switching to Thread 32072.32102]
> compress_r11eac_blocks () at
../../../../src/opts/SkTextureCompressor_opts.h:208
> 208	        vst1q_u64(dst1, d1);
> (gdb) bt
> #0  compress_r11eac_blocks () at
> ../../../../src/opts/SkTextureCompressor_opts.h:208
> #1  compress_a8_r11eac () at
../../../../src/opts/SkTextureCompressor_opts.h:231
> #2  0xb60629a4 in CompressBufferToFormat () at
> ../../../../src/utils/SkTextureCompressor.cpp:125
> #3  CompressBitmapToFormat () at
> ../../../../src/utils/SkTextureCompressor.cpp:157
> #4  0xb5312038 in test_CompressCheckerboard () at
> ../../../../tests/TextureCompressionTest.cpp:157
> #5  0xb512fb62 in run_test () at ../../../../dm/DM.cpp:1248
> #6  0xb5f853c6 in operator() ()
>     at
>
/home/joel/dev/skia/android_repo/platform_tools/android/bin/../toolchains/arm-r12b-14/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/functional:2439
> #7  Loop () at ../../../../src/core/SkTaskGroup.cpp:167
> #8  0xb6069f16 in thread_start () at
> ../../../../src/utils/SkThreadUtils_pthread.cpp:66
> #9  0xb6f67668 in __pthread_start(void*) ()
>    from
>
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
> #10 0xb6f65684 in __start_thread ()
>    from
>
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
> #11 0x00000000 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)

And reverting this change fixes that?
What's the connection between this change and the alignment of that store?
I don't see anything refcounted in SkTextureCompressor_opts.h.

[Joel.Liang, 2016-08-16 15:58:11]

On 2016/08/16 15:50:33, mtklein wrote:
> On 2016/08/16 15:48:18, Joel.Liang wrote:
> > On 2016/08/16 12:30:26, mtklein wrote:
> > > On 2016/08/16 06:18:02, Joel.Liang wrote:
> > > > On 2016/08/09 19:20:09, commit-bot: I haz the power wrote:
> > > > > Committed patchset #5 (id:80001) as
> > > > >
> > >
> https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6
> > > > 
> > > > This CL will cause "Bus error\n EXIT_CODE is 135" on Android devices.
> > > > You can run gm tests to reproduce this issue.
> > > > ./platform_tools/android/bin/android_run_skia dm --config gpu
> --resourcePath
> > > > /sdcard/skia_resources
> > > > 
> > > > I have tested on Huawei Mate 8, Samsung Note 10.1 and Samsung Galaxy S5.
> > > 
> > > I don't think we've seen that.  Can you post a stack trace?
> > 
> > 6.31m elapsed, 2 active, 81 queued, 48MB RAM, 1433MB peak
> > 	unit test  PathMeasure
> > 	unit test  SkSharedMutexMultiThreaded
> > [New Thread 32072.32102]
> > [New Thread 32072.32116]
> > [New Thread 32072.32117]
> > [New Thread 32072.32118]
> > [New Thread 32072.32119]
> > [New Thread 32072.32120]
> > [New Thread 32072.32121]
> > [New Thread 32072.32122]
> > [New Thread 32072.32126]
> > 
> > Thread 2 "skia_launcher" received signal SIGBUS, Bus error.
> > [Switching to Thread 32072.32102]
> > compress_r11eac_blocks () at
> ../../../../src/opts/SkTextureCompressor_opts.h:208
> > 208	        vst1q_u64(dst1, d1);
> > (gdb) bt
> > #0  compress_r11eac_blocks () at
> > ../../../../src/opts/SkTextureCompressor_opts.h:208
> > #1  compress_a8_r11eac () at
> ../../../../src/opts/SkTextureCompressor_opts.h:231
> > #2  0xb60629a4 in CompressBufferToFormat () at
> > ../../../../src/utils/SkTextureCompressor.cpp:125
> > #3  CompressBitmapToFormat () at
> > ../../../../src/utils/SkTextureCompressor.cpp:157
> > #4  0xb5312038 in test_CompressCheckerboard () at
> > ../../../../tests/TextureCompressionTest.cpp:157
> > #5  0xb512fb62 in run_test () at ../../../../dm/DM.cpp:1248
> > #6  0xb5f853c6 in operator() ()
> >     at
> >
>
/home/joel/dev/skia/android_repo/platform_tools/android/bin/../toolchains/arm-r12b-14/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/functional:2439
> > #7  Loop () at ../../../../src/core/SkTaskGroup.cpp:167
> > #8  0xb6069f16 in thread_start () at
> > ../../../../src/utils/SkThreadUtils_pthread.cpp:66
> > #9  0xb6f67668 in __pthread_start(void*) ()
> >    from
> >
>
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
> > #10 0xb6f65684 in __start_thread ()
> >    from
> >
>
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
> > #11 0x00000000 in ?? ()
> > Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> > (gdb)
> 
> And reverting this change fixes that?
> What's the connection between this change and the alignment of that store?
> I don't see anything refcounted in SkTextureCompressor_opts.h.

Yes, reverting this change can fix this issue.
I haven't done any investigation on this yet. Just confirmed by revert, build
and run test.
Have you manage to reproduce this issue?

[mtklein, 2016-08-16 16:02:18]

On 2016/08/16 15:58:11, Joel.Liang wrote:
> On 2016/08/16 15:50:33, mtklein wrote:
> > On 2016/08/16 15:48:18, Joel.Liang wrote:
> > > On 2016/08/16 12:30:26, mtklein wrote:
> > > > On 2016/08/16 06:18:02, Joel.Liang wrote:
> > > > > On 2016/08/09 19:20:09, commit-bot: I haz the power wrote:
> > > > > > Committed patchset #5 (id:80001) as
> > > > > >
> > > >
> >
https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6
> > > > > 
> > > > > This CL will cause "Bus error\n EXIT_CODE is 135" on Android devices.
> > > > > You can run gm tests to reproduce this issue.
> > > > > ./platform_tools/android/bin/android_run_skia dm --config gpu
> > --resourcePath
> > > > > /sdcard/skia_resources
> > > > > 
> > > > > I have tested on Huawei Mate 8, Samsung Note 10.1 and Samsung Galaxy
S5.
> > > > 
> > > > I don't think we've seen that.  Can you post a stack trace?
> > > 
> > > 6.31m elapsed, 2 active, 81 queued, 48MB RAM, 1433MB peak
> > > 	unit test  PathMeasure
> > > 	unit test  SkSharedMutexMultiThreaded
> > > [New Thread 32072.32102]
> > > [New Thread 32072.32116]
> > > [New Thread 32072.32117]
> > > [New Thread 32072.32118]
> > > [New Thread 32072.32119]
> > > [New Thread 32072.32120]
> > > [New Thread 32072.32121]
> > > [New Thread 32072.32122]
> > > [New Thread 32072.32126]
> > > 
> > > Thread 2 "skia_launcher" received signal SIGBUS, Bus error.
> > > [Switching to Thread 32072.32102]
> > > compress_r11eac_blocks () at
> > ../../../../src/opts/SkTextureCompressor_opts.h:208
> > > 208	        vst1q_u64(dst1, d1);
> > > (gdb) bt
> > > #0  compress_r11eac_blocks () at
> > > ../../../../src/opts/SkTextureCompressor_opts.h:208
> > > #1  compress_a8_r11eac () at
> > ../../../../src/opts/SkTextureCompressor_opts.h:231
> > > #2  0xb60629a4 in CompressBufferToFormat () at
> > > ../../../../src/utils/SkTextureCompressor.cpp:125
> > > #3  CompressBitmapToFormat () at
> > > ../../../../src/utils/SkTextureCompressor.cpp:157
> > > #4  0xb5312038 in test_CompressCheckerboard () at
> > > ../../../../tests/TextureCompressionTest.cpp:157
> > > #5  0xb512fb62 in run_test () at ../../../../dm/DM.cpp:1248
> > > #6  0xb5f853c6 in operator() ()
> > >     at
> > >
> >
>
/home/joel/dev/skia/android_repo/platform_tools/android/bin/../toolchains/arm-r12b-14/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/functional:2439
> > > #7  Loop () at ../../../../src/core/SkTaskGroup.cpp:167
> > > #8  0xb6069f16 in thread_start () at
> > > ../../../../src/utils/SkThreadUtils_pthread.cpp:66
> > > #9  0xb6f67668 in __pthread_start(void*) ()
> > >    from
> > >
> >
>
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
> > > #10 0xb6f65684 in __start_thread ()
> > >    from
> > >
> >
>
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
> > > #11 0x00000000 in ?? ()
> > > Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> > > (gdb)
> > 
> > And reverting this change fixes that?
> > What's the connection between this change and the alignment of that store?
> > I don't see anything refcounted in SkTextureCompressor_opts.h.
> 
> Yes, reverting this change can fix this issue.
> I haven't done any investigation on this yet. Just confirmed by revert, build
> and run test.
> Have you manage to reproduce this issue?

No, I have not yet tried.

[mtklein, 2016-08-16 16:03:25]

On 2016/08/16 16:02:18, mtklein wrote:
> On 2016/08/16 15:58:11, Joel.Liang wrote:
> > On 2016/08/16 15:50:33, mtklein wrote:
> > > On 2016/08/16 15:48:18, Joel.Liang wrote:
> > > > On 2016/08/16 12:30:26, mtklein wrote:
> > > > > On 2016/08/16 06:18:02, Joel.Liang wrote:
> > > > > > On 2016/08/09 19:20:09, commit-bot: I haz the power wrote:
> > > > > > > Committed patchset #5 (id:80001) as
> > > > > > >
> > > > >
> > >
> https://skia.googlesource.com/skia/+/b47cd4b3d6daad037651daa20fae6770285966d6
> > > > > > 
> > > > > > This CL will cause "Bus error\n EXIT_CODE is 135" on Android
devices.
> > > > > > You can run gm tests to reproduce this issue.
> > > > > > ./platform_tools/android/bin/android_run_skia dm --config gpu
> > > --resourcePath
> > > > > > /sdcard/skia_resources
> > > > > > 
> > > > > > I have tested on Huawei Mate 8, Samsung Note 10.1 and Samsung Galaxy
> S5.
> > > > > 
> > > > > I don't think we've seen that.  Can you post a stack trace?
> > > > 
> > > > 6.31m elapsed, 2 active, 81 queued, 48MB RAM, 1433MB peak
> > > > 	unit test  PathMeasure
> > > > 	unit test  SkSharedMutexMultiThreaded
> > > > [New Thread 32072.32102]
> > > > [New Thread 32072.32116]
> > > > [New Thread 32072.32117]
> > > > [New Thread 32072.32118]
> > > > [New Thread 32072.32119]
> > > > [New Thread 32072.32120]
> > > > [New Thread 32072.32121]
> > > > [New Thread 32072.32122]
> > > > [New Thread 32072.32126]
> > > > 
> > > > Thread 2 "skia_launcher" received signal SIGBUS, Bus error.
> > > > [Switching to Thread 32072.32102]
> > > > compress_r11eac_blocks () at
> > > ../../../../src/opts/SkTextureCompressor_opts.h:208
> > > > 208	        vst1q_u64(dst1, d1);
> > > > (gdb) bt
> > > > #0  compress_r11eac_blocks () at
> > > > ../../../../src/opts/SkTextureCompressor_opts.h:208
> > > > #1  compress_a8_r11eac () at
> > > ../../../../src/opts/SkTextureCompressor_opts.h:231
> > > > #2  0xb60629a4 in CompressBufferToFormat () at
> > > > ../../../../src/utils/SkTextureCompressor.cpp:125
> > > > #3  CompressBitmapToFormat () at
> > > > ../../../../src/utils/SkTextureCompressor.cpp:157
> > > > #4  0xb5312038 in test_CompressCheckerboard () at
> > > > ../../../../tests/TextureCompressionTest.cpp:157
> > > > #5  0xb512fb62 in run_test () at ../../../../dm/DM.cpp:1248
> > > > #6  0xb5f853c6 in operator() ()
> > > >     at
> > > >
> > >
> >
>
/home/joel/dev/skia/android_repo/platform_tools/android/bin/../toolchains/arm-r12b-14/bin/../lib/gcc/arm-linux-androideabi/4.9.x/../../../../include/c++/4.9.x/functional:2439
> > > > #7  Loop () at ../../../../src/core/SkTaskGroup.cpp:167
> > > > #8  0xb6069f16 in thread_start () at
> > > > ../../../../src/utils/SkThreadUtils_pthread.cpp:66
> > > > #9  0xb6f67668 in __pthread_start(void*) ()
> > > >    from
> > > >
> > >
> >
>
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
> > > > #10 0xb6f65684 in __start_thread ()
> > > >    from
> > > >
> > >
> >
>
/home/joel/dev/skia/android_repo/out/config/android-arm_v7_neon/android_gdb_tmp/libc.so
> > > > #11 0x00000000 in ?? ()
> > > > Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
> > > > (gdb)
> > > 
> > > And reverting this change fixes that?
> > > What's the connection between this change and the alignment of that store?
> > > I don't see anything refcounted in SkTextureCompressor_opts.h.
> > 
> > Yes, reverting this change can fix this issue.
> > I haven't done any investigation on this yet. Just confirmed by revert,
build
> > and run test.
> > Have you manage to reproduce this issue?
> 
> No, I have not yet tried.

This is tracked here: https://bugs.chromium.org/p/skia/issues/detail?id=5637