gnome-shell crashed with SIGSEGV in _int_malloc()

[dino99]

Zesty 64 bits and nvidia-375 driver

I often get a crash while doing some upgrades; some ends crashing but most of the upgrades do not.
This is happening since a year or so.
Today a new 'vim' version has been upgraded, and the crash happened after i've seen the first 'Processing triggers for ...'

....
Setting up vim-gui-common (2:8.0.0095-1ubuntu2) ...
Processing triggers for mime-support (3.60ubuntu1) ...
Setting up xxd (2:8.0.0095-1ubuntu2) ...
Processing triggers for desktop-file-utils (0.23-1ubuntu1) ...
Setting up pinentry-gnome3 (1.0.0-1) ...
Setting up vim-common (2:8.0.0095-1ubuntu2) ...
Processing triggers for man-db (2.7.5-2) ...
Setting up vim-runtime (2:8.0.0095-1ubuntu2) ...
Processing triggers for gnome-menus (3.13.3-6ubuntu4) ...
Processing triggers for hicolor-icon-theme (0.15-1) ...
Setting up vim-gtk3 (2:8.0.0095-1ubuntu2) ...
Setting up vim-tiny (2:8.0.0095-1ubuntu2) ...

so it seems that something in the upgrading scripts makes G-S crashing.
But the real package to blame might be an other one.

As apport does not send itself the details, i'm joining the crash file
---
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
DisplayManager: lightdm
DistroRelease: Ubuntu 17.04
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
Package: gnome-shell 3.22.1-1ubuntu2
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 4.9.0-6.7-generic 4.9.0-rc7
Tags: zesty third-party-packages
Uname: Linux 4.9.0-6-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom colord dip lpadmin nvidia-persistenced plugdev sambashare sudo users
_MarkForUpload: True

[dino99 (9d9)]

apport information

[dino99 (9d9)]

apport information

[dino99 (9d9)]

apport information

[dino99 (9d9)]

apport information

[Daniel van Vugt (vanvugt)]

If a program has crashed in malloc then it's already too late to debug. Unfortunately heap corruption has a delayed effect so even a perfect backtrace of such a crash won't tell you exactly where the corruption originated. You would need to use tooling such as Valgrind to debug the source of the corruption.

[dino99 (9d9)]

Time has passed, and that issue is no more seen nowadays. Let say it was a transitional problem with the continuous update schedule moving to the final gnome 3.22 version.