Fixed
Status Update
Comments
se...@google.com <se...@google.com> #2
Thank you for this feedback. The team may reach out for more information on triaging or reproducing this issue.
yb...@google.com <yb...@google.com> #3
pallavi@ - Have we done any testing on Win7? Looks like this issue should be easily reproducible.
yb...@google.com <yb...@google.com> #4
a.sworowska: could you click the "view problem details" button and send us what that shows?
zyy: is there any other useful information about a crash on Windows that's easily available?
zyy: is there any other useful information about a crash on Windows that's easily available?
yb...@google.com <yb...@google.com> #5
Problem signature:
Problem Event Name: APPCRASH
Application Name: adb.exe
Application Version: 0.0.0.0
Application Timestamp: 34f534d5
Fault Module Name: adb.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 34f534d5
Exception Code: 40000015
Exception Offset: 00016717
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 7763
Additional Information 2: 7763cd91f17ba1394e15130ad28436a8
Additional Information 3: 622c
Additional Information 4: 622c3aed538ac58f09882fe423edc57a
Also there's a console output: (for adb devices)
List of devices attached
* daemon not running. starting it now at tcp:5037 *
error: cannot open transport registration socketpair: Input/output error
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Problem Event Name: APPCRASH
Application Name: adb.exe
Application Version: 0.0.0.0
Application Timestamp: 34f534d5
Fault Module Name: adb.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 34f534d5
Exception Code: 40000015
Exception Offset: 00016717
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 7763
Additional Information 2: 7763cd91f17ba1394e15130ad28436a8
Additional Information 3: 622c
Additional Information 4: 622c3aed538ac58f09882fe423edc57a
Also there's a console output: (for adb devices)
List of devices attached
* daemon not running. starting it now at tcp:5037 *
error: cannot open transport registration socketpair: Input/output error
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
da...@gmail.com <da...@gmail.com> #6
We have the same problem at my workplace (computers running with the same configuration).
Changing the port (5037) didn't solve.
We were thinking about a conflict with the company's proxy but we gave up to find a solution as soon as we downgrade to 25.0.3 and understood that the update was responsible of the crash.
Changing the port (5037) didn't solve.
We were thinking about a conflict with the company's proxy but we gave up to find a solution as soon as we downgrade to 25.0.3 and understood that the update was responsible of the crash.
yb...@google.com <yb...@google.com> #7
>zyy: is there any other useful information about a crash on Windows that's easily available?
One can generate a minidump file on crash, here's instructions (WER part):https://blogs.msdn.microsoft.com/chaun/2013/11/12/steps-to-catch-a-simple-crash-dump-of-a-crashing-process/
Other option would be to integrate Breakpad (https://chromium.googlesource.com/breakpad/breakpad/ ); it will take much longer but would allow for automatic / user-initiated crash information submission
One can generate a minidump file on crash, here's instructions (WER part):
Other option would be to integrate Breakpad (
ap...@google.com <ap...@google.com> #8
I did the WER method and generate a dmp file (2 in fact because of the DumpCount set to 2... Should I set it higher ?)
But it is a 40MB file which I can't upload. Any suggestion ?
But it is a 40MB file which I can't upload. Any suggestion ?
Description
Version used: 2.2.0-alpha01
Devices/Android versions reproduced on: Android 9
I'm having some random crashes due to CoroutineLiveData
```
Fatal Exception: java.lang.IllegalArgumentException: This source was already added with the different observer
at androidx.lifecycle.MediatorLiveData.addSource + 89(MediatorLiveData.java:89)
at androidx.lifecycle.CoroutineLiveDataKt.addDisposableSource + 102(CoroutineLiveDataKt.java:102)
at androidx.lifecycle.CoroutineLiveData.emitSource$lifecycle_livedata_ktx_release + 200(CoroutineLiveData.java:200)
at androidx.lifecycle.LiveDataScopeImpl$emitSource$2.invokeSuspend + 89(LiveDataScopeImpl.java:89)
at androidx.lifecycle.LiveDataScopeImpl$emitSource$2.invoke(LiveDataScopeImpl.java:11)
at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn + 91(UndispatchedKt.java:91)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.withContext + 156(BuildersKt__Builders_commonKt.java:156)
at kotlinx.coroutines.BuildersKt.withContext + 1(BuildersKt.java:1)
at androidx.lifecycle.LiveDataScopeImpl.emitSource + 88(LiveDataScopeImpl.java:88)
at com.geekorum.ttrss.articles_list.FeedsViewModel$refreshed$1.invokeSuspend + 90(FeedsViewModel.java:90)
at com.geekorum.ttrss.articles_list.FeedsViewModel$refreshed$1.invoke(FeedsViewModel.java:8)
at androidx.lifecycle.BlockRunner$maybeRun$1.invokeSuspend + 147(BlockRunner.java:147)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith + 33(BaseContinuationImpl.java:33)
at kotlinx.coroutines.DispatchedTask.run + 241(DispatchedTask.java:241)
at android.os.Handler.handleCallback + 873(Handler.java:873)
at android.os.Handler.dispatchMessage + 99(Handler.java:99)
at android.os.Looper.loop + 193(Looper.java:193)
at android.app.ActivityThread.main + 6898(ActivityThread.java:6898)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run + 537(RuntimeInit.java:537)
at com.android.internal.os.ZygoteInit.main + 858(ZygoteInit.java:858)
```
From what I understand of CoroutineLiveData source code, when calling `LiveDataScope.emitSource()` the previous source is removed before adding the new one on MediatorLiveData.
```
@MainThread
internal fun emitSource(source: LiveData<T>): DisposableHandle {
clearSource()
val newSource = addDisposableSource(source)
emittedSource = newSource
return newSource
}
```
However the removing is done by launching a new coroutine
```
internal fun <T> MediatorLiveData<T>.addDisposableSource(
source: LiveData<T>
): DisposableHandle {
val disposed = AtomicBoolean(false)
addSource(source) {
if (!disposed.get()) {
value = it
} else {
removeSource(source)
}
}
return object : DisposableHandle {
override fun dispose() {
if (disposed.compareAndSet(false, true)) {
CoroutineScope(Dispatchers.Main).launch {
removeSource(source)
}
}
}
}
}
```
So there is no guarantee that `MediatorLiveData.addSource()` will be called after the removing coroutine is executed. This leads to the IllegalArgumentException in `MediatorLiveData.addSource()`
```
@MainThread
public <S> void addSource(@NonNull LiveData<S> source, @NonNull Observer<? super S> onChanged) {
Source<S> e = new Source<>(source, onChanged);
Source<?> existing = mSources.putIfAbsent(source, e);
if (existing != null && existing.mObserver != onChanged) {
throw new IllegalArgumentException(
"This source was already added with the different observer");
}
if (existing != null) {
return;
}
if (hasActiveObservers()) {
e.plug();
}
}
```