https://bugs.kde.org/show_bug.cgi?id=507625
--- Comment #7 from Michał <[email protected]> --- > That said, there's also some slight problem with the solib=file mapping > dance inside drkonqi. At a glance it can happen that the file is None and > still gets loaded, that's the bogus `add symbol table from file "None"` in > your output. There definitely is, I could tell that from my general GDB shenanigans beforehand. The path from app's perspective can be wholly invalid from crash reporter's/debugger's external perspective, it might be gone, be bogus to begin with, be mapped into a sandbox with a different path (such as with stuff ran in Steam runtime for example). And even if it's there, there's no guarantee it's the same file (say on regular distro, if you ran a system upgrade, but had a program running with old zombie-file version of the library, your script would load the new version and probably screw with dump analysis within Sentry, or have it be completely discarded as invalid (in case that last possibility isn't accounted for by something like a checksum check, I have no idea if it is or not)). Also in my experience setting up some crash reporting stuff (on a different OS), conceptually inspecting the original memory of crashed app as much as possible rather than re-loading anything can go a long way, I once saw a crash where the code section with actual processor instructions was just corrupted (and even had the opportunity to contact the user, and they said they indeed were tinkering with unstable memory overclocking to have caused that). > The way things work is that when there isn't enough RAM to load all symbols > (which would generally be more reliable) we instead walk all frames manually > and for each frame resolve the library it belongs to based on the memory > addresses involved and then run `sharedlibrary` and `add-symbol-file` in gdb > to load whatever data is available such that the next frame may be resolved. > That's where things fall over, one of the frames fails to find a suitable > mapping in your eu-unstrip data and so things explode. So it is conditional then? I have 16 GB of memory on that machine (possibly no swap? I don't remember). I guess ideally there'd be some method to both avoid memory exhaustion and avoid trying to load the libraries anew from the disk. > Probably needs reporting to your distribution as this indeed only happens > with the mentioned distributions, according to our crash database. I can actually see more-less what the issue is. These .file files would actually reside at /ostree/repo/objects/ (or physically rather /sysroot/ostree/repo/objects/, as /sysroot is mounted on /). So the final path would be something like /ostree/repo/objects/29/5c45f94ee5681696fb209cb4d505ca67b966d2dab16859fe5ff361ed48e991.file Perhaps they set that library path somewhere for some early loader in similar way to how NixOS does its shenanigans? Well thankfully these very first few frames responsible for startup shouldn't matter much at all, other than just ensuring they don't cause DrKonqi to bail out and lose all potentially all crash reports from these distros. But I'm not sure if it can be considered an upstream bug frankly, these reported paths as I mentioned above cannot be guaranteed to correspond to physical paths from the perspective of all processes (as happens with sandboxes and stuff), it's downstream app that decided to rely on them in this way. And with that I said I hope there is indeed some better way to handle cases like this (I'd be glad to know actually if there is, since I was screwn over by similar issue before in general), in case you decide it's worth it to pursue/implement some better method for probably rare/minuscule cases like this. Is there maybe a chance it could be as simple as pointing GDB or that other tool at an extra library directory to try resolving? (at least to cover OSTree's case?) (inb4 fakesysroot with those two-letter dir names symlinked into its root) -- You are receiving this mail because: You are watching all bug changes.
