Fixed
Status Update
Comments
ra...@google.com <ra...@google.com> #2
Project: chromiumos/overlays/chromiumos-overlay
Branch: main
commit d9fcf3ac6751e611ab8a1970310ac6e7bf01f463
Author: Alec Bargher <abargher@google.com>
Date: Wed Aug 21 15:51:24 2024
dev-util: Add workaround for armv7a boards compiling LLDB
Currently armv7a is not parsed as a supported architecture by LLDB.
Compiling with the host architecture in the triple set to "arm" instead
of "armv7a" can work around this issue before LLDB itself is patched.
BUG=b:361414339
TEST=USE="local-lldb" cros build-packages --board=${BOARD}
Change-Id: I7c18ab9354b09fd91ac3635a8bcb4ac177f0d3cd
Reviewed-on:https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/5805607
Reviewed-by: Jordan Abrahams-Whitehead <ajordanr@google.com>
Commit-Queue: Alec Bargher <abargher@google.com>
Tested-by: Alec Bargher <abargher@google.com>
Commit-Queue: ChromeOS Auto Runner <chromeos-auto-runner@chromeos-bot.iam.gserviceaccount.com>
M dev-util/lldb-server/lldb-server-9999.ebuild
https://chromium-review.googlesource.com/5805607
Branch: main
commit d9fcf3ac6751e611ab8a1970310ac6e7bf01f463
Author: Alec Bargher <abargher@google.com>
Date: Wed Aug 21 15:51:24 2024
dev-util: Add workaround for armv7a boards compiling LLDB
Currently armv7a is not parsed as a supported architecture by LLDB.
Compiling with the host architecture in the triple set to "arm" instead
of "armv7a" can work around this issue before LLDB itself is patched.
BUG=b:361414339
TEST=USE="local-lldb" cros build-packages --board=${BOARD}
Change-Id: I7c18ab9354b09fd91ac3635a8bcb4ac177f0d3cd
Reviewed-on:
Reviewed-by: Jordan Abrahams-Whitehead <ajordanr@google.com>
Commit-Queue: Alec Bargher <abargher@google.com>
Tested-by: Alec Bargher <abargher@google.com>
Commit-Queue: ChromeOS Auto Runner <chromeos-auto-runner@chromeos-bot.iam.gserviceaccount.com>
M dev-util/lldb-server/lldb-server-9999.ebuild
ca...@careem.com <ca...@careem.com> #3
We should see if we can upstream a proper fix for this "armv7a" in particular is not an uncommon form in the target triple. Working on a patch now.
Description
I have created a Worker and a test class running it, but the doWork method is not called.
I have tried to debug the issue and the work is not executed as the constructor of `TestWorkManagerImpl` creates a list of Schedulers with one `null` Scheduler. due to this the Schedulers.schedule method throws a null pointer exception.
Here is the stacktrace from the exception:
androidx.work.impl.Schedulers.schedule(Schedulers.java:91)
androidx.work.impl.utils.EnqueueRunnable.scheduleWorkInBackground(EnqueueRunnable.java:131)
androidx.work.impl.utils.EnqueueRunnable.run(EnqueueRunnable.java:92)
androidx.work.testing.TestWorkManagerImpl$1.executeOnBackgroundThread(TestWorkManagerImpl.java:63)
androidx.work.impl.WorkContinuationImpl.enqueue(WorkContinuationImpl.java:185)
androidx.work.impl.WorkManagerImpl.enqueue(WorkManagerImpl.java:305)
androidx.work.WorkManager.enqueue(WorkManager.java:180)
com.example.carlo.myapplication.testWorker() <--- where WorkManager.getInstance().enqueue(request) is called
I have also created a project with one failing test.
I am using WorkManager 1.0.0-beta01
Please let me know if you need more information