fwupd crashed with SIGSEGV in _int_malloc()

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

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

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

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

Threadstacktrace with dbgsym

Stacktrace+dbgsym

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

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

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

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

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?

Bug #1663548

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

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

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

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

@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,

having the same issue on a Lenovo Thinkpad x230

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.

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. :-)

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,

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.

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.

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