This was a big disaster crash on graphene

CGG

Any one can clarify this?

type: logcat
osVersion: google/komodo/komodo:16/BP3A.251105.015/2025112101:user/release-keys
buffers: crash
level: verbose

--------- beginning of crash
11-30 23:32:42.855  root   467   467 F libc    : Unwind request: crash_dump helper failed to exec, or was killed
11-30 23:32:43.405  1017   482   482 F libc    : Unwind request: crash_dump helper failed to exec, or was killed
11-30 23:33:36.412  root   467   467 F libc    : Unwind request: crash_dump helper failed to exec, or was killed
11-30 23:33:36.944  1017   482   482 F libc    : Unwind request: crash_dump helper failed to exec, or was killed
11-30 23:33:43.493 1201000  4288  4288 E AndroidRuntime: FATAL EXCEPTION: main
11-30 23:33:43.493 1201000  4288  4288 E AndroidRuntime: Process: com.android.settings, PID: 4288
11-30 23:33:43.493 1201000  4288  4288 E AndroidRuntime: DeadSystemException: The system died; earlier logs will point to the root cause
11-30 23:33:43.496 10129  2116  2270 E AndroidRuntime: FATAL EXCEPTION: BroadcastRunning
11-30 23:33:43.496 10129  2116  2270 E AndroidRuntime: Process: com.android.systemui, PID: 2116
11-30 23:33:43.496 10129  2116  2270 E AndroidRuntime: DeadSystemException: The system died; earlier logs will point to the root cause
11-30 23:33:43.498 radio  2398  2751 E AndroidRuntime: FATAL EXCEPTION: SatelliteController
11-30 23:33:43.498 radio  2398  2751 E AndroidRuntime: Process: com.android.phone, PID: 2398
11-30 23:33:43.498 radio  2398  2751 E AndroidRuntime: DeadSystemException: The system died; earlier logs will point to the root cause
11-30 23:33:43.507 10118  2374  2972 E AndroidRuntime: FATAL EXCEPTION: PixelDisplayManager
11-30 23:33:43.507 10118  2374  2972 E AndroidRuntime: Process: com.android.pixeldisplayservice, PID: 2374
11-30 23:33:43.507 10118  2374  2972 E AndroidRuntime: DeadSystemException: The system died; earlier logs will point to the root cause
11-30 23:33:43.509 10107  4057  4327 E AndroidRuntime: FATAL EXCEPTION: pool-3-thread-1
11-30 23:33:43.509 10107  4057  4327 E AndroidRuntime: Process: com.android.messaging, PID: 4057
11-30 23:33:43.509 10107  4057  4327 E AndroidRuntime: DeadSystemException: The system died; earlier logs will point to the root cause
11-30 23:33:43.509  1073  2274  4050 E AndroidRuntime: FATAL EXCEPTION: Thread-2
11-30 23:33:43.509  1073  2274  4050 E AndroidRuntime: Process: com.android.networkstack.process, PID: 2274
11-30 23:33:43.509  1073  2274  4050 E AndroidRuntime: DeadSystemException: The system died; earlier logs will point to the root cause
11-30 23:33:43.510 10105  3535  3535 E AndroidRuntime: FATAL EXCEPTION: main
11-30 23:33:43.510 10105  3535  3535 E AndroidRuntime: Process: com.android.inputmethod.latin, PID: 3535
11-30 23:33:43.510 10105  3535  3535 E AndroidRuntime: DeadSystemException: The system died; earlier logs will point to the root cause

Tandara

CGG The logs you provided only show consequences of that crash. We would need earlier logs to see the reason.

de0u

CGG Did this happen just once?

CGG

Sorry guys for the late response and thanks for the attention. Actually @Tandara it was impossible to retrieve the earlier logs since after a reboot they vanish. What happened was: This log was generated after changing to a user profile which couldn´t log in successfully and after that the crash occured. The phone was in mobile phone only ( without internet) and simply crashed when the profile have changed. I tryed to collect the logs before but it wasn´t possible. It was a big crash to the system since i was presented after crash two option on the bootloader: something like to try a reboot or restore to factory settings. Which I didn´t choose just by simply restarting the phone. @de0u That happened 5 times yesterday and the GOS is on its latest version (with security previews enabled) 2025112101 and it seems a problem that happened to me on 2025111801 release but just once and after that, things have solved for itself. Seems some crash based on those two last versions since i have never experienced this crash before. The thing is that the latest version since its launch (i got it on beta) seems pretty stable.

RokeJulianLockhart

CGG, could it be related to issuetracker.google.com/issues/425896312#comment14? I've occasional system_server deaths that appear to be caused by a myriad of actions, some merely more frequent than others.

That would be an incredible coincidence if so, considering I'm solely here because I searched for google.com/search?q=crash_dump+helper+failed+to+exec%2C+or+was+killed, which returned this URI. Though, reddit.com/r/AndroidQuestions/comments/1g6fvjn/comment/nsr0e0e might indicate that they're vaguely related.

CGG

I don´t think at all it could be a security issue but a potential interaction between SystemServer and the simultaneous / general failure of applications failing in some kind of chain reaction. Something like a kernel bug or a SystemServer problem.

CGG

Hello RokeJulianLockhart well it seems for me some crash that happens specifically when you are changing your profile. Probably occurred by a bug in the logic when you switch user. That happened to me in a non constant reproductible situation. There is a lot of possible explanations for this to happen but the issue itself solved before some reboots. This never happened in main account.

RokeJulianLockhart

CGG, that's why I mention it: all the system_server deaths that I've thus far encountered have been very inconsistently reproducible. Regardless, in the future, if you install something like LogFox, and utilise its Shizuku backend, it'll likely be able to capture any unexpected logcat logs (at least, from --buffer=crash) before a reboot.

Otherwise, the advice, that has been told to me by Google engineers, has been to capture an adb bugreport immediately after reboot (that means before unlock). However, because you're, luckily, using GrapeheneOS, if this reproduces again, try submitting your diagnostic data to their issue tracker first. (If you do, tell me!)

MetropleX

RokeJulianLockhart utilise its Shizuku backend

No, no, no, no, no, do not use Shizuku or open up usb debugging.

You should be able to grab everything you need from:

SETTINGS > SYSTEM> VIEW LOGS > SAVE/SHARE

We expose the logs here and app specific ones via App Info to avoid this.

CGG

MetropleX i have this bug posted here at first and seeing a user posting on this topic

RokeJulianLockhart i understand but i think this is so random that will never happen again... Maybe a kernel bug but for my point of view far away from a security issue ... Much by the contrary.. Mostly because of a security enforcement than a security flaw. So for that reason, possibly i will not go forward on this crash.

RokeJulianLockhart

MetropleX, does that store crash logs, even after the ring buffer has been wiped (upon reboot)? If so, that's superb, although someone shall need to evaluate whether, in practice, it stores logs generated during shutdown – I, at least, have confirmed that the aforecited combination does.

MetropleX

RokeJulianLockhart it should but regardless instead of doing USB Debugging etc, you can also just use the bug report feature in developer options which definitely does persist after reboot. Then disable dev options again.

Our official stance:

ADB exposes an enormous amount of attack surface.
If you have ADB access, you can enable perf events, but there's a lot more attack surface via ADB than that and it's as close as it gets to having root access without an exploit.
ADB has near full control of the device, but isn't meant to actually have root access on a production build. It can be used to do everything you can do via the UI but also far more which expose a lot of attack surface.
ADB isn't advisable on a production device either way.

RokeJulianLockhart

you can also just use the bug report feature in developer options which definitely does persist after reboot

MetropleX, if you're referring to adb shell input keyevent --longpress KEYCODE_POWER's “Bug Report” option:

<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<hierarchy rotation="0">
	<node index="0" text="" resource-id="" class="android.widget.FrameLayout" package="com.android.systemui">
		<node index="0" text="" resource-id="" class="android.widget.FrameLayout">
			<node index="0" text="" resource-id="android:id/content" class="android.widget.FrameLayout">
				<node index="0" text="" resource-id="com.android.systemui:id/global_actions_container" class="android.view.ViewGroup">
					<node index="0" text="" resource-id="com.android.systemui:id/global_actions_view" class="android.widget.LinearLayout">
						<node index="0" text="" resource-id="android:id/list" class="android.view.ViewGroup">
							<node index="0" text="" resource-id="com.android.systemui:id/list_flow" class="android.view.View" />
							<node index="5" text="" resource-id="" class="android.widget.LinearLayout">
								<node index="0" text="" resource-id="android:id/icon" class="android.widget.ImageView" />
								<node index="1" text="Bug report" resource-id="android:id/message" class="android.widget.TextView"/>
							</node>
						</node>
					</node>
				</node>
			</node>
		</node>
	</node>
</hierarchy>

...then that's no different to adb bugreport, which solely retroactively captures logs currently available in the ring buffer, to my knowledge. Even if it captures logs stored elsewhere, it certainly doesn't continue to capture them until the subsequent reboot.

Is that what you meant?

Or maybe you discovered something on this crash that make this finding so important?

It's occurring on multiple devices at a very low level. I'm aware that correlation does not equate to causation, so all I've wanted to contribute is that if this recurs, attempt to capture logs if you're able to. Thanks.

CGG

Or maybe you discovered something on this crash that make this finding so important?