fwupd crashed with SIGSEGV in _int_malloc()

[AnuxiVM]

possible *workaround*
Comment out PrivateUsers=yes from /lib/systemd/system/fwupd.service

ProblemType: Crash
DistroRelease: Ubuntu 17.04
Package: fwupd 0.8.0-1
ProcVersionSignature: Ubuntu 4.9.0-16.17-generic 4.9.6
Uname: Linux 4.9.0-16-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
CrashCounter: 1
Date: Fri Feb 10 11:36:20 2017
ExecutablePath: /usr/lib/fwupd/fwupd
InstallationDate: Installed on 2017-02-10 (0 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Alpha amd64 (20170209)
ProcCmdline: /usr/lib/fwupd/fwupd
ProcEnviron:
 LANG=es_ES.UTF-8
 PATH=(custom, no user)
Signal: 11
SourcePackage: fwupd
StacktraceTop:
 _int_malloc (av=av@entry=0x7f9048af2b00 <main_arena>, bytes=bytes@entry=72) at malloc.c:3413
 __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at malloc.c:3271
 g_malloc0 () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 g_closure_new_simple () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 g_cclosure_new () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
Title: fwupd crashed with SIGSEGV in _int_malloc()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

[Apport retracing service (apport)]

StacktraceTop:
 _int_malloc (av=av@entry=0x7f9048af2b00 <main_arena>, bytes=bytes@entry=72) at malloc.c:3413
 __libc_calloc (n=<optimized out>, elem_size=<optimized out>) at malloc.c:3271
 g_malloc0 () from /tmp/apport_sandbox_jj8QDg/lib/x86_64-linux-gnu/libglib-2.0.so.0
 g_closure_new_simple () from /tmp/apport_sandbox_jj8QDg/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 g_cclosure_new () from /tmp/apport_sandbox_jj8QDg/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0

[Fabio Marconi (fabiomarconi)]

It affects me too just after enabling wifi with a usb wifi adapter inserted .
Best regards and thanks

[Fabio Marconi (fabiomarconi)]

It affects me too just after enabling wifi with a usb wifi adapter inserted .
Best regards

[Fabio Marconi (fabiomarconi)]

The presence of the wifi adapter is not related to this bug, it crashes even without it.
After the crash system is unusable and hardware power off is required.
Reproduced on real hardware

[Fabio Marconi (fabiomarconi)]

Threadstacktrace with dbgsym

[Fabio Marconi (fabiomarconi)]

Stacktrace+dbgsym

[Fabio Marconi (fabiomarconi)]

SegvAnalysis:
 Segfault happened at: 0x7f8eec398c8d <_int_malloc+109>: mov 0x10(%r14),%rdx
 PC (0x7f8eec398c8d) ok
 source "0x10(%r14)" (0x561200000010) not located in a known VMA region (needed readable region)!
 destination "%rdx" ok

[Fabio Marconi (fabiomarconi)]

feb 13 20:21:47 ZealantZebra systemd[1]: Failed to start Firmware update daemon.

[Iain Lane (laney)]

I see this too. For me it goes away if I comment out PrivateUsers=yes from /lib/systemd/system/fwupd.service.

[Richard Hughes (richard-hughes)]

If you comment out the NoNewPrivileges=yes in /usr/lib/systemd/system/fwupd.service -- does this now start normally?

[comptastic (comptastic)]

Commenting out NoNewPrivileges=yes in /lib/systemd/system/fwupd.service does not fix the issue.

Commenting out PrivateUsers=yes from /lib/systemd/system/fwupd.service fixes it for me!

So is this an appropriate workaround? What is the root of this issue?

[Dimos lampros (dimos33)]

Bug #1663548

How can I destroy the bug? What do I need to do?

[Fabio Marconi (fabiomarconi)]

as this crash was originally reported via apport I revert it back to bag for the fix

[Fabio Marconi (fabiomarconi)]

As this crash was originally reported by apport I revert it back to a bug report

[Iain Lane (laney)]

I filed https://github.com/dell/libsmbios/pull/13 which is now waiting for review

[Mario Limonciello (superm1)]

@laney

Thanks for digging into that. I think that's definitely a part that should be solved, but at least in the interim I believe this can be avoided in fwupd too by only running this code on supported systems.

Can you please check if https://github.com/hughsie/fwupd/commit/e70e5513cae8a74a5a3cd4376ff8c8f963892386
helps you with the existing libsmbios?

If so, I'll issue a new build to Debian with that integrated and we can track the libsmbios task separately.

Thanks,

[Achim Behrens (k1l)]

having the same issue on a Lenovo Thinkpad x230

[Achim Behrens (k1l)]

Ok, the workaround with commenting out PrivateUsers=yes from /lib/systemd/system/fwupd.service worked here, too, on the 17.04 on the Lenovo Thinkpad x230.

fuwpd is not crashing anymore. But i dont really know what the consequences of this workaround are.

[Iain Lane (laney)]

Mario,

Just tried your commits (on top of the Debian pkg) and they seem to fix the crash for me. I tried on an XPS 13 9350 and on a random desktop machine. The problem also happened for me in a VM. I didn't try that patch in there, but that might be a good way for you to try the error path.

I also didn't try a success path because I don't have hardware for that - assuming you will.

Cheers for working on this. Please upload if your testing also looks good. :-)

[Mario Limonciello (superm1)]

I spent some more time with this today and concluded that it is systemd confinement that is causing a majority of this headache. The stuff that was happening with crashes was just the tip. There were further problems with refreshing not working, flashing not working too.

I believe this commit should resolve all of the issues thus far:
https://github.com/hughsie/fwupd/commit/20c112a8911a4d89469a37f925edbc415fad25d4

If someone affected can please apply that locally to their systemd unit (/lib/systemd/system/fwupd.service) and confirm, it would be appreciated.

Thanks,

[Walter Garcia-Fontes (walter-garcia)]

Does this bug affect the access to google accounts? After updating to zeisty, I can access "www.google.com", but "mail.googl.com", for instance, times out.

[Walter Garcia-Fontes (walter-garcia)]

Forget about comment #25, can't access "mail.google.com" from a particular wifi network (eduroam), maybe there is a new bug there but I will investigate further.

[Launchpad Janitor (janitor)]

This bug was fixed in the package fwupd - 0.8.1-3

---------------
fwupd (0.8.1-3) unstable; urgency=medium

  * Backport upstream commit to make valgrind optional (Closes: #856344)
  * Backport upstream commit to make /boot/efi optional to start
    fwupd.service.

 -- Mario Limonciello <email address hidden> Tue, 28 Feb 2017 08:30:56 -0600