FS#45343 - [systemd] Upgrade to 220 caused segfault in (unrelated?) 3rd party app

Attached to Project: Arch Linux
Opened by Ng Oon-Ee (ngoonee) - Tuesday, 16 June 2015, 04:32 GMT
Last edited by Dave Reisner (falconindy) - Friday, 19 June 2015, 18:59 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
After upgrade of systemd, libsystemd, and systemd-sysvcompat from 219-6 to 220-5, I get segfaults in openni2, a library used to access 3D USB cameras (Asus Xtion Pro Live in my case). I first observed this in my own project which links openni2, then found the same to occur with SimpleViewer, an executable provided with openni2 to test basic functionality.

Recompiling openni2 does not change behaviour, which is to be expected as it should not be linking to systemd in any way.

I had previously asked about this on [arch-general][1].

I understand the affected app is not in the repos, but the problem occurs due to update of systemd, and I don't know enough to track down what causes this, or even make a proper bug report to the openni2 bug tracker.

Additional info:
* package version(s)
systemd-220-5, libsystemd-220-5, systemd-sysvcompat-220-5
* config and/or log files etc.
none


Steps to reproduce:
Simply upgrade to the version mentioned and run the SimpleViewer binary in openni2 (from the AUR[2].

[1] - https://lists.archlinux.org/pipermail/arch-general/2015-June/039336.html
[2] - https://aur.archlinux.org/packages/openni2/
This task depends upon

Closed by  Dave Reisner (falconindy)
Friday, 19 June 2015, 18:59 GMT
Reason for closing:  Fixed
Additional comments about closing:  systemd 221
Comment by Dave Reisner (falconindy) - Tuesday, 16 June 2015, 13:21 GMT
You'll need to debug further than this. At a minimum, you'll need to get a stack trace with debug symbols to pinpoint where the failure occurs. Ideally, you can bisect systemd to figure out where the bug was introduced, or test systemd from git to see if the failure still occurs.
Comment by AK (Andreaskem) - Tuesday, 16 June 2015, 17:35 GMT
"Recompiling openni2 does not change behaviour, which is to be expected as it should not be linking to systemd in any way."

According to an OpenNI2 README I found, the library links to libudev which is part of systemd.

From the systemd-220 changelog:
"A new (currently still internal) API sd-device.h has been added to libsystemd. This modernized API is supposed to replace libudev eventually. In fact, already much of libudev is now just a wrapper around sd-device.h."

Maybe something broke in the process.
Comment by Ng Oon-Ee (ngoonee) - Thursday, 18 June 2015, 04:14 GMT
falconindy, here's the results from bisection. Seems to match with what Andreaskem says. Is this sufficient? Recompiling openni2 with debug symbols has been done but gdb doesn't seem to show anything as the error turns out in libc (as far as I can ascertain). Anyway, included a link to the trace at the end.

c32eb440bab953a0169cd207dfef5cad16dfb340 is the first bad commit
commit c32eb440bab953a0169cd207dfef5cad16dfb340
Author: Tom Gundersen <teg@jklm.no>
Date: Tue Apr 14 16:25:06 2015 +0200

libudev: make libudev-enumerate a thin wrapper around sd-device

:100644 100644 837fd36381315029171562b344dca8620528d327 68d8252b84c13591cf8e0b0e15a99780f5dd0309 M Makefile.am
:040000 040000 c54e32bc21e34cc28693fbf653c4128a0383d3d7 11e1eeec94338e9294e25e720007c35f229d24cf M src

Trace.log - https://www.dropbox.com/s/ngpjjer3g6vamrn/trace.log?dl=0
Comment by Dave Reisner (falconindy) - Thursday, 18 June 2015, 13:22 GMT
There were numerous fixes in this area. systemd 221 will be out Soon™, but you could also try with systemd from git. If you still see the same segfaults, please report this upstream (github.com/systemd).
Comment by Ng Oon-Ee (ngoonee) - Friday, 19 June 2015, 03:11 GMT
Thanks falconindy, I'll proceed there. Just to verify first though, I took the systemd PKGBUILD from core and added the pkgver function (no other changes), which resulted (yesterday) in the following version - pkgver=220.0.gdde8bb3

Does this mean I'm running the latest git commit? Not sure how version numbering works for systemd, but if they follow convention I guess this would mean I'm still on 220 (as 221 is not out yet) but tracking commit gdde8bb3.
Comment by Ng Oon-Ee (ngoonee) - Friday, 19 June 2015, 03:14 GMT
Actually scratch that, I think I'm not on the latest at all as git log shows May 21st. I'll try to modify the PKGBUILD appropriately.
Comment by Ng Oon-Ee (ngoonee) - Friday, 19 June 2015, 03:49 GMT
Okay, I now have the latest git (latest commit Jun 19th) and I cannot reproduce. I assume there's no benefit to bisecting to find which commit fixes the bug to cherry-pick, as this is not happening with an official package, so closing the bug makes sense.

Tangentially, the systemd-git PKGBUILD I got from doing this is miles better (in my opinion) than the cruft currently masquerading as systemd-git (which draws from a different git repo even) in AUR3, thanks the the official PKGBUILD already pulling directly from git anyway. Will re-look at that when AUR4 fully takes over.

Loading...