https://bugs.kde.org/show_bug.cgi?id=507625
Harald Sitter <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDSINFO |CONFIRMED Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- --- Comment #5 from Harald Sitter <[email protected]> --- Probably needs reporting to your distribution as this indeed only happens with the mentioned distributions, according to our crash database. The problem is with these frames #36 0x00005605367877ad n/a (/29/5c45f94ee5681696fb209cb4d505ca67b966d2dab16859fe5ff361ed48e991.file + 0xf7ad) #37 0x00007fe66726e5f5 __libc_start_call_main (libc.so.6 + 0x35f5) #38 0x00007fe66726e6a8 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x36a8) #39 0x0000560536788a45 n/a (/29/5c45f94ee5681696fb209cb4d505ca67b966d2dab16859fe5ff361ed48e991.file + 0x10a45) These likely fail to map correctly and so we can't trace things. Indeed we can see that coredumpd also failed to trace them and it generally has more information than we do. 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. 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. -- You are receiving this mail because: You are watching all bug changes.
