raw_ptr<DanglingUntriaged> causing test crashes?

[Andrew Grieve]

I'm trying to debug flaky test failures:

https://ci.chromium.org/ui/test/chromium/ninja%3A%2F%2Fchrome%2Fandroid%3Achrome_public_test_apk%2Forg.chromium.chrome.browser.autofill.settings.AutofillProfilesFragmentTest%23testDeleteLocalProfile

The tests all have stacks like:

Stack Trace:
  RELADDR   FUNCTION                                                                          FILE:LINE
  06c76627  void base::allocator::(anonymous namespace)::DanglingRawPtrReleased<(base::features::DanglingPtrMode)0, (base::features::DanglingPtrType)1>(unsigned int)  partition_alloc_support.cc:0:0
  06d42cac  partition_alloc::internal::DanglingRawPtrReleased(unsigned int)                   dangling_raw_ptr_checks.cc:0:0
  02c4c6ed  base::internal::RawPtrBackupRefImpl<false, false>::ReleaseInternal(unsigned int)  raw_ptr_backup_ref_impl.cc:0:0
  09008fd8  autofill::AutofillDataModelChange<autofill::AutofillProfile>::~AutofillDataModelChange()  personal_data_manager.cc:0:0
  0904d997  base::internal::BindState<base::RepeatingCallback<void (autofill::AutofillProfileDeepChange const&)>, autofill::AutofillProfileDeepChange>::~BindState()  autofill_webdata_backend_impl.cc:0:0
  0904d966  base::internal::BindState<base::RepeatingCallback<void (autofill::AutofillProfileDeepChange const&)>, autofill::AutofillProfileDeepChange>::Destroy(base::internal::BindStateBase const*)  autofill_webdata_backend_impl.cc:0:0
  06b1f74f  base::internal::BindStateHolder::~BindStateHolder()                               callback_internal.cc:0:0

AutofillDataModelChange has only a single field:

raw_ptr<const DataType, DanglingUntriaged> data_model_

From what I can tell, "DanglingUntriaged" should not cause crashes. The type in the stack is:

base::internal::RawPtrBackupRefImpl<false, false>

I think those template args mean "do crash".

Before I try to add printfs and repro locally, anyone know if I've got something wrong with how raw_ptr works?

[dan...@chromium.org]

The untriaged raw_ptr will not trigger a DanglingPointerDetector assertion. I am guessing that's not what the crash here is.

What does the crash you're seeing look like? I see the stack but not the type of termination. Is the AutofillDataModelChange being destroyed twice? Is it a segfault? is the raw_ptr invalid and doing something bad as a result?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABiQX1ULh2q6dNT4C9cQgSEznrb56fGsSMFw%2BhOyATjmS720jw%40mail.gmail.com.

[Andrew Grieve]

Here's the full crash:

https://luci-logdog.appspot.com/logs/chromium/android/swarming/logcats/62cdc973ddb7ce11/+/tombstones_tombstones_20230613T141715-UTC_emulator-5554

tombstone_16 created on 2023-06-13 08:17:00, about this long ago: 7:00:06 Device: emulator-5554
Build fingerprint: 'google/sdk_gphone64_x86_64/emulator64_x86_64_arm64:12/SE1A.211012.001/7818354:userdebug/dev-keys'
Revision: '0'
pid: 27243, tid: 27243, name: um.chrome.tests  >>> org.chromium.chrome.tests <<<
signal 5 (SIGTRAP), code 128 (SI_KERNEL), fault addr 0x0

From AutofillProfilesFragmentTest#testDeleteLocalProfile on this bot.

I thought the "RawPtrBackupRefImpl<false, true>::ReleaseInternal(unsigned long)" meant that it was a dangling pointer assertion (the first template arg is named "AllowDangling").

[dan...@chromium.org]

On Wed, Jun 14, 2023 at 1:29 PM Andrew Grieve <agr...@google.com> wrote:

Here's the full crash:

https://luci-logdog.appspot.com/logs/chromium/android/swarming/logcats/62cdc973ddb7ce11/+/tombstones_tombstones_20230613T141715-UTC_emulator-5554

tombstone_16 created on 2023-06-13 08:17:00, about this long ago: 7:00:06 Device: emulator-5554
Build fingerprint: 'google/sdk_gphone64_x86_64/emulator64_x86_64_arm64:12/SE1A.211012.001/7818354:userdebug/dev-keys'
Revision: '0'
pid: 27243, tid: 27243, name: um.chrome.tests  >>> org.chromium.chrome.tests <<<
signal 5 (SIGTRAP), code 128 (SI_KERNEL), fault addr 0x0

From AutofillProfilesFragmentTest#testDeleteLocalProfile on this bot.

I thought the "RawPtrBackupRefImpl<false, true>::ReleaseInternal(unsigned long)" meant that it was a dangling pointer assertion (the first template arg is named "AllowDangling").

Ok yeah, false there means no dangling. But it's determined from /*AllowDangling=*/Contains(Traits, RawPtrTraits::kMayDangle)

And DanglingUntriaged is an alias to kMayDangle.

So uh, not sure now.

If you build with the same GN args and such you should be able to examine the type that's getting created there and verify that the first parameter is actually true? If not, then we can debug that. If it is true, then the stack trace is wrong-ish?

[Arthur Sonzogni]

Hi Andrew,

+CC @pmeuleman FYI.

The unmerged patch you linked above is directly updating the meaning of `DanglingUntriaged`. So this explains why you get AllowDangling turned off contrary to the behavior on trunk.

This patch seems not meant to be merged. It only fails many tests in many try-jobs associated with this particular CL. So I wouldn't worry about this failure.

That being said, if a single patch is failing so many tests that you personally notice, then it probably mean we should try to be more gentle on the CQ and save some cycles.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Peter Boström]

It's not immediately obvious to me why we should flake test on the trybots. Do we not get enough data about flaky tests in CI or are we worried about discrepancies in gn args or bot configurations?

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CABiQX1ULh2q6dNT4C9cQgSEznrb56fGsSMFw%2BhOyATjmS720jw%40mail.gmail.com.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/0191264b-2c13-4074-94dc-12c1d595699fn%40chromium.org.

[Andrew Grieve]

Ah! Thanks for noticing this! I didn't even realize I was looking at trybots!

I agree Peter - I'll follow-up and see if we can have trybots labelled or excluded from the test history page.

[Andrew Grieve]

Filed via feedback link on test history page: https://bugs.chromium.org/p/chromium/issues/detail?id=1455095