Obsolete
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
I've experienced this problem on several different android devices when using operator++ of std::atomic. I switched to boost::atomic as a temporary workaround. This bug exists on other platforms (windows using mingw) so it isn't specific to android.
in...@ffimprov.org
boost::atomic doesn't automatically suffice as a workaround, since it uses std::atomic unless you tell it not to (such as by defining the flag BOOST_AC_USE_PTHREADS), and notably the Boost.Asio library requires you to define BOOST_ASIO_DISABLE_STD_ATOMIC. There may be other libraries as well within Boost that require customization to prevent the use of std::atomic.
di...@android.com
Will look into it, thanks for the attached program, it will be useful.
di...@android.com
FYI, I can reproduce the issue with the small native executable whose source code is attached here (on Nexus S + official 4.1.2, non-rooted).
en...@google.com
my...@gmail.com
Hello, should I make a new ticket for this? I'm only able to reproduce this only on a subset Snapdragon 835 devices on the new LLVM stack.
I'm seeing almost the exact same issue doing a similar test.
I'm actually able to reproduce this same exact issue only on a subset of Snapdragon 835 devices using the following:
* r16b (release and debug), r17b (release and debug), r18 (debug works fine, release replicates the error)
* libc++
* clang
The following devices (Snapdragon 835) experience this issue:
* Pixel 2
* Pixel 2 XL
* LG V30
(Have not tested this on an LG G6 or Samsung Galaxy S8)
The following Snapdragon 835 does NOT experience this issue:
* Samsung Galaxy Note 8
I've tried a similar test on other generations of devices (Galaxy S9, Nexus 6P, 5X, Moto G5 Plus, Samsung Galaxy S4), and they don't experience this issue.
I know this is really old, but I was wondering if it makes sense to look into this same issue, either on this ticket or on a new ticket.
I'm seeing almost the exact same issue doing a similar test.
I'm actually able to reproduce this same exact issue only on a subset of Snapdragon 835 devices using the following:
* r16b (release and debug), r17b (release and debug), r18 (debug works fine, release replicates the error)
* libc++
* clang
The following devices (Snapdragon 835) experience this issue:
* Pixel 2
* Pixel 2 XL
* LG V30
(Have not tested this on an LG G6 or Samsung Galaxy S8)
The following Snapdragon 835 does NOT experience this issue:
* Samsung Galaxy Note 8
I've tried a similar test on other generations of devices (Galaxy S9, Nexus 6P, 5X, Moto G5 Plus, Samsung Galaxy S4), and they don't experience this issue.
I know this is really old, but I was wondering if it makes sense to look into this same issue, either on this ticket or on a new ticket.
en...@google.com
gnustl was removed in r18. if you can reproduce this with r18 using clang and libc++, please file a new bug at https://github.com/android-ndk/ndk/issues providing all the detail asked for by the template.
Description
Observed on a Nexus 4 running Android 4.2, an HTC Sense running Android 2.3.4, and numerous other devices. Tested in ndk-r8c and ndk-r8d. This is using gnustl as the C++ standard library.
The attached sample program demonstrates this. With the default configuration, 1 thread repeatedly incrementing a std::atomic<long> in a tight loop very quickly crashes.
Other configuration options in hello-thread.cpp can add threads, allow the threads intermittently sleep, etc:
- Turn off USE_ATOMIC to switch to a regular, non-atomic variable, and experience expected behavior (counter keeps incrementing every second).
- I can easily make 64 threads access the same std::atomic variable WITHOUT crashing if they sleep in-between each access. But once they iterate a few thousand times before sleeping, a crash is virtually guaranteed in the first 30 seconds of running, no matter how many threads are present.
Dan.