Harlan Lieberman-Berg <hlieber...@setec.io> writes: > Would it be possible for you to use rr to capture a dump of the > segfault for me?
I tried before filing the report; rr doesn't work with sysdig, apparently > Hm, this is strange. I've tested this a couple of different ways, > including on a clean sid box and a sid box with libc downgraded to the > same version as on your machine, but I can't recreate the error. Well, this isn't satisfying. I just ran an experiment, trying to see if gcc-10 had any hand in this. The kernel module is compiled locally on the user's box (gcc-10 here, presumably), but the userspace is built by the Debian boxes (gcc-9) presumably. I just did this: 1. Check out the sysdig sources from upstream. Same tag as the version of the Debian package I have. 2. Build sysdig (userspace + kernel) from source with my default compiler (gcc-10). This takes forever because it insists on building all of its dependencies. There was a small build issue with the bundled libgrpc++ that I fixed; it isn't interesting. 3. I installed the just-built kernel module, and ran the just-built sysdig tool. No segfault 4. I installed the built-from-package kernel module, that was part of the crashing runs earlier, and ran the just-built sysdig tool. No segfault 5. I installed the built-from-package kernel module, that was part of the crashing runs earlier, and ran the packaged sysdig tool. No segfault #5 is this bug report, but this thing works now. I can't break it anymore. I haven't installed or removed any packages between now and when it was broken, so I can't explain this. I should also say that sysdig was unusable on this box for months, AND I confirmed the segfault before filing this report, so this bug report wasn't based on a one-off failure or anything. During those months I did rebuild/rmmod/modprobe the kernel module several times, and that didn't fix anything. Let me dogfood this for a few days, and if I consistently can't reproduce the failure I'll close this bug. Sorry for the noise
