Why doesn't kill -SEGV kill chrome processes?

148 views
Skip to first unread message

i...@chromium.org

unread,
Mar 22, 2019, 7:27:21 PM3/22/19
to Chromium-dev
I've noticed that kill -SEGV doesn't seem to kill chrome processes, and I'm a little confused as to why. 

This is on Chrome OS. I know that crashpad will attempt to intercept SEGV and write out minidumps, but I would expect that after 10 minutes, the process would have exited. Or that crash_reporter would be running. Or that I could see a crash report. Something. But it's still merrily running along:

localhost ~ # kill -SEGV 10642
localhost ~ # date
Fri Mar 22 15:27:19 PDT 2019
localhost ~ # date
Fri Mar 22 15:38:31 PDT 2019
localhost ~ # ps aux | grep 10642
chronos  10642  0.0  0.4 524176 71452 ?        Sl   15:24   0:00 /opt/google/chrome/chrome --type=renderer --enable-logging --enable-webgl-image-chromium --log-level=1 --use-gl=egl --vmodule=*arc/*=1,*/chromeos/power/auto_screen_brightness/*=1,*/forced_extensions/installation_tracker*=2,extension_downloader=2,*/feedback_uploader*=1,*/feedback_private/*=1,existing_user_controller=2,*/ash/wm/tablet_mode/*=1,nss_cert_database_chromeos=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2 --enable-surface-synchronization --field-trial-handle=16490985078519489473,13744978928235188372,131072 --enable-features=ChromeOSAssistant,Crostini,EnableBackgroundBlur,ExperimentalCrostiniUI,MachineLearningService,MyFilesVolume,Pepper3DImageChromium,PointerEvent --lang=en-US --enable-crash-reporter=e697f201-785e-4d01-9a24-ffd9263c73e0,unknown --user-data-dir=/home/chronos --homedir=/home/chronos/u-88f73114661efcb732d5f8704867614caaf4ecbc --login-profile=user --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=32.0.0.161 --num-raster-threads=2 --enable-main-frame-before-activation --service-request-channel-token=18198915919896300988 --renderer-client-id=140 --no-v8-untrusted-code-mitigations --shared-files=v8_natives_data:100,v8_snapshot_data:101
root     12142  0.0  0.0   4424   908 pts/0    S+   15:38   0:00 grep --colour=auto 10642
localhost ~ # ps aux | grep crash_reporter
root     12153  0.0  0.0   4424   916 pts/0    S+   15:38   0:00 grep --colour=auto crash_reporter
localhost ~ # 


I can kill chrome processes with kill -9 so it's not that the signals aren't delivered.

Does Chrome just ignore SIGSEGV completely? That seems weird; if we actually were referencing bad memory, it seems like we should exit. 

It would be very useful to me to be able to send SIGSEGV to chrome at will; makes it easier to debug crash_reporter. Any hints as to why this is happening?

Thanks
Ian


Mike Frysinger

unread,
Mar 22, 2019, 7:36:58 PM3/22/19
to Ian Barkley-Yeung, Chromium-dev
seems like it catches the signal & processes it.  not an uncommon or unreasonable behavior.  you could look at its /proc/xxx/status file to specifically check its signal masks.

if you look at `man 7 signal` it'll show many signals that result in coredumps, so see if there are ones that Chrome doesn't register handlers for.

as for crash_reporter not running, that's probably a good thing.  it's supposed to be fast and exit asap.  watch /var/log/messages for its progress.
-mike

--
--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/81086881-344d-43c8-9add-671927e31f4d%40chromium.org.

Ian Barkley-Yeung

unread,
Mar 22, 2019, 7:50:01 PM3/22/19
to Mike Frysinger, Chromium-dev
I know it's catching the signal. What I'm asking is why Chrome doesn't exit once crashpad / crash_reporter finish handling the signal. 

Most other programs I've worked on would catch the signal long enough to write out information about the crash, and then exit because they were in a bad state and didn't want to try and keep working while in a bad state. I'm wondering why the programmers who created Chrome chose to keep it running after a segmentation fault. 

Lei Zhang

unread,
Mar 22, 2019, 7:51:50 PM3/22/19
to i...@chromium.org, Chromium-dev
FWIW, my Chromium build on Linux does die when it gets a SIGSEGV. It
also properly exists when it gets a SIGTERM.

On Fri, Mar 22, 2019 at 4:28 PM <i...@chromium.org> wrote:
>

Primiano Tucci

unread,
Mar 23, 2019, 12:59:44 AM3/23/19
to Lei Zhang, Ian Barkley-Yeung, Chromium-dev
Segv is one of the signals that is supposed to be re-thrown until the cause of it is resolved (it never happens unless you are doing some fancy userspace page fault handling) . The crash reporter relies on this behavior.
What happens is that your Segv signal is intercepted correctly by the crash handler which generates a minidump. However, when the crash handler returns the signal will not reach chrome (because the signal handler consumed it and   nothing is regenerating it). In real life, when the crash handler exits, the kernel would send another signal to chrome and kill it, because the crash handler doesn't solve the cause of Segv. 

The story is completely different for other signals like -ABRT. if you look at breakpad / Crashpad code you will see that it had a special path that manually re-fires that signal before leaving the crash handler, precisely for this reason. That's why kill -ABRT does what you expect but kill -SEGV doesn't. 

Ian Barkley-Yeung

unread,
Mar 25, 2019, 5:05:26 PM3/25/19
to Primiano Tucci, Lei Zhang, Chromium-dev
OK, thanks, nice to know the reasoning.

I don't see any code in crashpad that handles ABRT differently from SEGV; and indeed, kill -ABRT also doesn't seem to kill chrome processes in Chrome OS. I do see some code in breakpad; is that what you are referring to? Maybe kill -ABRT will work once Chrome-on-Chrome-OS is using breakpad.

Thanks,
Ian


Mike Frysinger

unread,
Mar 25, 2019, 5:19:14 PM3/25/19
to Ian Barkley-Yeung, Primiano Tucci, Lei Zhang, Chromium-dev
Chrome-on-Chrome-OS is using breakpad now ...
-mike

Ian Barkley-Yeung

unread,
Mar 25, 2019, 5:39:54 PM3/25/19
to Mike Frysinger, Primiano Tucci, Lei Zhang, Chromium-dev
Sorry, right, Monday. 

Then it's still weird that kill -ABRT doesn't work:
localhost ~ # ps aux | grep 15201
chronos  15201  0.0  0.4 524176 71160 ?        Sl   13:42   0:00 /opt/google/chrome/chrome --type=renderer --enable-logging --enable-webgl-image-chromium --log-level=1 --use-gl=egl --vmodule=*arc/*=1,*/chromeos/power/auto_screen_brightness/*=1,*/forced_extensions/installation_tracker*=2,extension_downloader=2,*/feedback_uploader*=1,*/feedback_private/*=1,existing_user_controller=2,*/ash/wm/tablet_mode/*=1,nss_cert_database_chromeos=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2 --enable-surface-synchronization --field-trial-handle=3360951378113585594,355668465894419039,131072 --enable-features=ChromeOSAssistant,Crostini,EnableBackgroundBlur,ExperimentalCrostiniUI,MachineLearningService,MyFilesVolume,Pepper3DImageChromium,PointerEvent --lang=en-US --enable-crash-reporter=e697f201-785e-4d01-9a24-ffd9263c73e0,unknown --user-data-dir=/home/chronos --homedir=/home/chronos/u-88f73114661efcb732d5f8704867614caaf4ecbc --login-profile=user --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=32.0.0.161 --num-raster-threads=2 --enable-main-frame-before-activation --service-request-channel-token=13995863933640843066 --renderer-client-id=26 --no-v8-untrusted-code-mitigations --shared-files=v8_natives_data:100,v8_snapshot_data:101
root     20926  0.0  0.0   4424   912 pts/0    S+   14:35   0:00 grep --colour=auto 15201
localhost ~ # kill -ABRT 15201
localhost ~ # ps aux | grep 15201
chronos  15201  0.0  0.4 524176 71336 ?        Sl   13:42   0:00 /opt/google/chrome/chrome --type=renderer --enable-logging --enable-webgl-image-chromium --log-level=1 --use-gl=egl --vmodule=*arc/*=1,*/chromeos/power/auto_screen_brightness/*=1,*/forced_extensions/installation_tracker*=2,extension_downloader=2,*/feedback_uploader*=1,*/feedback_private/*=1,existing_user_controller=2,*/ash/wm/tablet_mode/*=1,nss_cert_database_chromeos=1,*chromeos/login/*=1,auto_enrollment_controller=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,update_engine=1,component_updater_service=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2 --enable-surface-synchronization --field-trial-handle=3360951378113585594,355668465894419039,131072 --enable-features=ChromeOSAssistant,Crostini,EnableBackgroundBlur,ExperimentalCrostiniUI,MachineLearningService,MyFilesVolume,Pepper3DImageChromium,PointerEvent --lang=en-US --enable-crash-reporter=e697f201-785e-4d01-9a24-ffd9263c73e0,unknown --user-data-dir=/home/chronos --homedir=/home/chronos/u-88f73114661efcb732d5f8704867614caaf4ecbc --login-profile=user --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=32.0.0.161 --num-raster-threads=2 --enable-main-frame-before-activation --service-request-channel-token=13995863933640843066 --renderer-client-id=26 --no-v8-untrusted-code-mitigations --shared-files=v8_natives_data:100,v8_snapshot_data:101
root     20961  0.0  0.0   4424   808 pts/0    S+   14:35   0:00 grep --colour=auto 15201

Reply all
Reply to author
Forward
0 new messages