[frameworks-baloo] [Bug 389848] baloo_file crashes in mdb_put() in LMDB
https://bugs.kde.org/show_bug.cgi?id=389848 --- Comment #184 from Howard Chu --- (In reply to Guillaume B. from comment #183) > I had an issue similar to this recently, tell me if you need more traces There's nothing for anyone else to do for now. baloo needs to be fixed to stop deleting the lockfile on active LMDB databases. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 389848] baloo_file crashes in mdb_put() in LMDB
https://bugs.kde.org/show_bug.cgi?id=389848 --- Comment #182 from Howard Chu --- (In reply to tagwerk19 from comment #181) > (In reply to Howard Chu from comment #180) > > ... I suppose we may as well merge it, since it has no impact if MDB_DEBUG > > is not defined ... > We'd need to run Baloo with a specially compiled LMDB to get the trace? Yes. But that's easily done, just set LD_LIBRARY_PATH to pick up your debug build. > Yes, all the same, I can provide "Gentle Words of Encouragement" for the > merge and many thanks to your "additional user". The more tools we have to > troubleshoot, the better :-) Yeah, it will probably go into the next official release. But at this point there's not much else for us to do, baloo is clearly breaking LMDB's writer lock. https://bugs.openldap.org/show_bug.cgi?id=9378#c18 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 389848] baloo_file crashes in mdb_put() in LMDB
https://bugs.kde.org/show_bug.cgi?id=389848 --- Comment #180 from Howard Chu --- The logging in the branch I referred to here https://git.openldap.org/hyc/openldap/-/tree/mplay09?ref_type=heads is only available when LMDB is compiled with -DMDB_DEBUG, and I haven't decided whether to actually merge that branch into a release or not. I suppose we may as well merge it, since it has no impact if MDB_DEBUG is not defined. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 389848] baloo_file crashes in mdb_put() in LMDB
https://bugs.kde.org/show_bug.cgi?id=389848 Howard Chu changed: What|Removed |Added Resolution|UPSTREAM|--- CC||h...@symas.com Status|RESOLVED|REOPENED --- Comment #178 from Howard Chu --- Copying from https://bugs.openldap.org/show_bug.cgi?id=9378 Thanks to assistance from another user, we've made some progress setting up a KDE test environment to reproduce this issue. Using the replay logging facility in this branch https://git.openldap.org/hyc/openldap/-/tree/mplay09?ref_type=heads we collected a trace from one of the crash instances. The suspicious part is excerpted here: >mdb_put: 0x5638e7e58130, 2, 8[646f6d696e616e74], 16, 0 >mdb_put: 0x5638e7e58130, 3, 8[646f6d696e616e74], 24, 0 >mdb_put: 0x5638e7e58130, 2, 8[74656c6c74616c65], 8, 0 >mdb_put: 0x5638e7e58130, 3, 8[74656c6c74616c65], 11, 0 >mdb_put: 0x5638e7e58130, 2, 3[747874], 56200, 0 >mdb_env_create: 0x559276b2ddc0 >mdb_env_set_maxdbs: 0x559276b2ddc0, 12 >mdb_env_set_mapsize: 0x559276b2ddc0, 274877906944 >mdb_env_open: 0x559276b2ddc0, /home/vm/.local/share/baloo/index, 16793600, 0664 >mdb_txn_begin: 0x559276b2ddc0, (nil), 0 = 0x559276b2f1c0 >mdb_dbi_open: 0x559276b2f1c0, postingdb, 262144 = 2 >mdb_dbi_open: 0x559276b2f1c0, positiondb, 262144 = 3 >mdb_dbi_open: 0x559276b2f1c0, docterms, 262152 = 4 >mdb_dbi_open: 0x559276b2f1c0, docfilenameterms, 262152 = 5 >mdb_dbi_open: 0x559276b2f1c0, docxatrrterms, 262152 = 6 >mdb_dbi_open: 0x559276b2f1c0, idtree, 262152 = 7 >mdb_dbi_open: 0x559276b2f1c0, idfilename, 262152 = 8 >mdb_dbi_open: 0x559276b2f1c0, documenttimedb, 262152 = 9 >mdb_dbi_open: 0x559276b2f1c0, documentdatadb, 262152 = 10 >mdb_dbi_open: 0x559276b2f1c0, indexingleveldb, 262152 = 11 >mdb_dbi_open: 0x559276b2f1c0, failediddb, 262152 = 12 >mdb_dbi_open: 0x559276b2f1c0, mtimedb, 262204 = 13 >mdb_txn_commit: 0x559276b2f1c0 >mdb_put: 0x5638e7e58130, 3, 3[747874], 91570, 0 >mdb_put: 0x5638e7e58130, 2, 2[6368], 464, 0 >mdb_put: 0x5638e7e58130, 3, 2[6368], 1286, 0 >mdb_put: 0x5638e7e58130, 2, 7[766172696f7573], 1440, 0 >mdb_put: 0x5638e7e58130, 3, 7[766172696f7573], 2282, 0 In the middle of txn 0x5638e7e58130 the init sequence occurs again, and all of the contents of this logfile are only being written by a single process. That means baloo_file has opened the same env twice in the same process, which is explicitly forbidden by the LMDB docs. http://www.lmdb.tech/doc/ Going to close this ticket as Invalid, it's a KDE bug and not an LMDB bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 229500] mmap with huge size fails under valgrind
https://bugs.kde.org/show_bug.cgi?id=229500 Howard Chu changed: What|Removed |Added CC||h...@symas.com --- Comment #5 from Howard Chu --- I see memcheck has an --ignore-range commandline option to bypass checks on an address range. Would it be possible to define a client request to ignore mmap(...,size) ? Meaning that the immediately subsequent mmap request would be passed thru to the kernel, and the resulting memory would be ignored by valgrind, so it doesn't need to fit in valgrind's address space management. I was just about to open a wishlist ticket for this feature, but stumbled across this bug report along the way. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 79362] Debug info is lost for .so files when they are dlclose'd
https://bugs.kde.org/show_bug.cgi?id=79362 --- Comment #61 from Howard Chu <h...@symas.com> --- Julian Seward wrote: > https://bugs.kde.org/show_bug.cgi?id=79362 > > --- Comment #59 from Julian Seward <jsew...@acm.org> --- > (In reply to Howard Chu from comment #57) > >> a clean fix has been available for nearly 5 years. > > I'm trying to understand the proposed fix. What I've gathered is: > > (1) Each ExeContext has a 32-bit unique ID. > > (2) m_execontext.c issues unique IDs in a monotonically increasing sequence, > from ec_next_ecu. > > (3) The patch extends struct DebugInfo so as to record the unique ID (2) at > both the time the DebugInfo came into being and the point at which the > associated .so was unmapped. > > (4) DebugInfos for objects that have been unmapped are moved into their own > linked list (unloadedDebugInfo_list) > > (5) When symbolicating an ExeContext, I assume that you use its unique to > identify which set of DebugInfos in unloadedDebugInfo_list can > participate in its symbolisation (viz, should be used to look up symbol > names etc). > > This seems somewhat plausible. But what I don't understand is how this > interacts with the fact that m_execontext doesn't necessarily issue a new > ExeContext with a new unique every time a stack unwind is requested. > Instead, it unwinds the stack, then checks to find if it already has an > ExeContext with that stack. If so it merely gives out a pointer to the > existing version rather than creating a new one. > > I'm not saying the patch is wrong. I am saying I don't understand it. Was > the m_execontext duplicate-stack-removal behaviour taken into account in the > design of the fix? It's been so long I don't remember the fine details any more. But I think it's safe to say, most of the time, if a shared object has been unloaded and a different one has been loaded, even if mapped to the same base address as the previous object, it is unlikely to have the same sizes and ordering of functions as the previous object, and thus unlikely to produce duplicates of any existing stack traces. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 358548] baloo_file_extractor high CPU and memory usage
https://bugs.kde.org/show_bug.cgi?id=358548 --- Comment #8 from Howard Chu <h...@symas.com> --- (MDB_VL32 is not in a public release, only in mdb.master.) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 358548] baloo_file_extractor high CPU and memory usage
https://bugs.kde.org/show_bug.cgi?id=358548 Howard Chu <h...@symas.com> changed: What|Removed |Added CC||h...@symas.com --- Comment #7 from Howard Chu <h...@symas.com> --- (In reply to Stefan Brüns from comment #6) > Fun fact: > LMDB on-disk format seems to be dependent on sizeof(ptr_t) - I can open the > db index file on my 32bit RPi1, but not on my x86_64. Correct, LMDB files are architecture-dependent. If you want to avoid this word-size dependency, you should define MDB_VL32 when building on 32bit arches - then it will be 64bit clean and identical to the 64bit build. -- You are receiving this mail because: You are watching all bug changes.
