[spam][crazy][log] gdb, thread local, libgit, instruction pointet
I'm debugging a slowdown in my data generator for the adapters for semibalanced trees stuff. I have a lightweight c++ iterator to loop through repository references and to find which branch a random commit came from. The hang is happening inside the function that uses this iterator. I have a breakpoint set when a match is found. It extracts the name of the branch and stores it in a static thread local variable, a quick way to reuse heap allocation for dynamic strings. gdb is presently looping on this breakpoint, despite it being followed by a return statement.
i booted up a web browser so as to paste in gdb snippets, and went to get some water while i waited as the system has heavy i/o slowing things down as it collates git commits in the background when i returned gdb had crashed, without any user interaction: Breakpoint 6, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:91 (gdb) terminate called after throwing an instance of 'std::length_error' what(): cannot create std::vector larger than max_size() Aborted (core dumped) I guess if this stuff gets too weird I might need a [poltergeists] tag or something to go alongside [crazy]
$ gdb --version GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2 $ b2sum $(type -p gdb) e8a7e79ea79b2bc0977313899484136f34be865cd6032a26c1841a256d4b18a99b51dd8d0f05710ec5b3ee4da23041fc6872bd3650246bc0efc9fb050f902ff4 /usr/bin/gdb $ ldd $(type -p gdb) | sed -ne 's/.* => \(.*\) (.*/\1/p' | xargs b2sum 9668d759a14ca244ad5d0e6d4a5eb308ec50b4c01b4e242c8d63acded57237788f346e0faec95efae2d20b8c6e9bb19c748b218fd8c85b16c17a58e9ed4ec5b5 /lib/x86_64-linux-gnu/libreadline.so.8 db18fb1f72489870ee52201ad2e2f1d1718896b659ecf8881aeb002faa7791678a3ad3efb3084c05498a91abc8850768447b71e06a9b9ab055b5e3c58135296b /lib/x86_64-linux-gnu/libz.so.1 c3ce0f4a4a417f395f8a722c14327d23d2df128e30171f0ba310a3ed42efef2de3f6106029884d6393172e5679988563d9007ff6535b7d4892a72064c65532a1 /lib/x86_64-linux-gnu/libncursesw.so.6 d0e42f9f8ea3e3581031e232a4c595a6579385863c2929d0eed20fe2ebf8a4bff43c714a3857e402a6177afd0fad9da2e506a4fb7a25e2cd675146f7469278de /lib/x86_64-linux-gnu/libtinfo.so.6 f04910fe141c18dcc3e8997a4e0103514b252240b4538a61b507cc45fa23f0997064871cb1c98b75f819c8e065b110c7f18d8026677ab296e7c603d3902141e6 /lib/x86_64-linux-gnu/libdl.so.2 2b1e97873e763c3ed1dd93d16b71c8183fd05e167a0b7f2ec652f1440a9de1bc48739c7e57423c7585f4f4b40c265b679b2185040d77e46c8b93fbdbdddd9734 /lib/x86_64-linux-gnu/libpython3.8.so.1.0 904ba7926418426e2db0b6e5c453c489b5e58b88389359c379db8a526f4319d8bfd5f53e9b0de26d5299e9c8bfda2bc1e95446203266a4ee2af33f0a26e0c064 /lib/x86_64-linux-gnu/libpthread.so.0 37a469cb58a133bbf12fa4c6a0e27b7bbf7427f72375c1bfd63226d0e03dc622cb3a22b6e93605e9e79f6ad52bbf743ea2ad59fe987acb0d7457bc3158f8a4d3 /lib/x86_64-linux-gnu/libm.so.6 e9cb3462e57194b26582de0f181afecabc76be2b6f5dd0cc81f8febade9c53c1ec03ebed50174b1dfdb0a92884eac394d285665e383d7abfe1f0f5a780164b7a /lib/x86_64-linux-gnu/libexpat.so.1 4b1d915cc0fc825b04dfc2f8ec5f10caa46dca5e59828ddc7e9655c6d05331efce2dc7be38be8664e2eb1e725fb95fef95e2d74d5271041722a3db5fb90a99a2 /lib/x86_64-linux-gnu/liblzma.so.5 f5cb9bec376d6420b81e9aa1b41f0785c558f1e9ebc611f00a2228f5a282daf488cf30ea3b699ae7a138821f3f582e24f0f085333e30afd7666f46cb45e9ef7b /lib/x86_64-linux-gnu/libbabeltrace.so.1 d377a989f53f02703f631aad25d1bde2162bb038b99d89a997e4c5c20d57a27a0e347f16d3d6784882b901505f5eacbf2e62b75fb41280b06967e58735dbfa51 /lib/x86_64-linux-gnu/libbabeltrace-ctf.so.1 1c7f68b27a6fd89bf69b3519ff59c487768c5d7ec4bd7737219db77351ce1db5fa93bddc32c87913131f09923cf01ab13fa5a532f344e5cc18bc5b259463020d /lib/x86_64-linux-gnu/libmpfr.so.6 d7a17f3b0a61a0579a378c4b2d7eeebcf3111447d33ead7b5309e114a2e8594f68bb0cb6ccdfb07c76f8a96d8b065a36a062bca38bd827e2ce8fc2249f920042 /lib/x86_64-linux-gnu/libstdc++.so.6 9f95b51580ccb1244944133a8701218363b132c24d181daa4644e95bd9a4f4264b30ef40efbf1088102cf8e388dab9126eae53bbb46eceb332a637b618307d6b /lib/x86_64-linux-gnu/libgcc_s.so.1 fde559ba19ee629c55653b124e57a09ae742b1fcd29be50d7905445628e1acee354846201516b8ad0cf7d4de2b39e68d7546c2238924652968bed9b130b6118c /lib/x86_64-linux-gnu/libc.so.6 0a1897439b3d178084f607b8a427718ff079ec364cf1007535c3d4b579412f894cf49617d9075ef10ecc9efea57e88221f6a4c7c98482b70faa3eda790d5aa86 /lib/x86_64-linux-gnu/libutil.so.1 30e2d9c4e69ecfce64d32d0e5bef36129ebaa8d404b55af01c274d7403e989c6b39ce116af2e3d75e3902baa41bddff8a47644677c21430b6acfdbe20a69b754 /lib/x86_64-linux-gnu/libglib-2.0.so.0 310c271739d8c75c32a711911482c5a4ecf811f5f7fae44700dc1897e735faabc36f09596e19f709c73ae30735bdd54c6a2d846244a0bd610a504b23e154db78 /lib/x86_64-linux-gnu/libdw.so.1 208f0494a69b897d7e865626c624a31ca058e544b8f53b4c7a5db7c39f2a2ffa83ffef539b3ed001a7c4786285e87560751fd078f012012075f0e00c8cd99652 /lib/x86_64-linux-gnu/libelf.so.1 96785dd583ce71127aa574888897318c00494d12aeee93a6268170477990c0d1db48064637800dbf94fea69812677f67a2384193d2f70808678164cc78c2bf25 /lib/x86_64-linux-gnu/libuuid.so.1 d4cbfb48b7a6218bdb92bcc48c481e1f07b66e55d70d2ac0f969d36a76a4b6117e82fb800a4e0cd9fa2dca0209b1c1ebcfc3a3659e45cba0008dfa2192da9138 /lib/x86_64-linux-gnu/libgmp.so.10 9ca97298a37534c99e45e8a2610678a63fad7da172402b8109e2906139995a9502e4ae329f911c91ea4b600767dd25fdb16a44664a4f08bfe8fdb75821cc1394 /lib/x86_64-linux-gnu/libpcre.so.3 9692713222413a6c3f32547d860769fd4122b60810495a71a389e804b3d9002c48b9a0a91bcea8e7dc8b13c69d2f6172655843732d0e57ff59ca230592c03ca2 /lib/x86_64-linux-gnu/libbz2.so.1.0
process2.cpp is my code, so i'm imagining the most likely scenario here is that i typed something into gdb that stimulated finding the crash, and forgot when i walked away.
ok, this time i stepped into the first call and it turns out the return statement is throwing an exception inside it, and gdb's "step" and "nexti" commands do not step into the exception handler, instead continuing. the iterator theoretically steps to the next value and the breakpoint is hit again. i'm guessing that i had let it run too many times last time, and some bug caused an overflow and memory corruption, maybe
i have things making sense now, having placed a breakpoint inside the exception handler. finally gdb is behaving in a normal way around the issue. i guess it would make sense to run it under valgrind
notes: thread local name setting is line 92. handler is line 96. handler appends to list.
On 8/7/22, Undiscussed Groomed for Male Slavery, One Victim of Many <gmkarl@gmail.com> wrote:
ok, this time i stepped into the first call and it turns out the return statement is throwing an exception inside it, and gdb's "step" and "nexti" commands do not step into the exception handler, instead continuing. the iterator theoretically steps to the next value and the breakpoint is hit again
i'm guessing that i had let it run too many times last time, and some bug caused an overflow and memory corruption, maybe
To clarify here, after posting this email thread, this was the first time gdb would let me inspect the data as the system was running. Previously I was getting errors regarding inability to access thread local data, or to set a breakpoint on the next instruction inside code without debugging symbols. I experienced the looping that appears to now be from a thrown exception (and that looks like what should be happening, the thrown exception) even when I was using the "si" and "ni" commands to single step through individual assembly instructions. Previously, when I used "si" to step into library code that _does_ have debugging symbols, gdb would show ?? for the function name. This time, it let me step into the call and review the exceptional case a little. This is why I consider memory corruption. Not sure what from, the code in the loop is not complex. I have these old gdb interactions in my scrollback buffer, likely, although I have since resized the window containing the tmux session.
so while valgrind finds that the error is my mind, not my system, i'll paste some scrollback in .... here's where i identified that the hang was within the remote_name() function. i set a breakpoint within it and restarted execution: 410 auto remote_name = repo_entry->remote_name(commit_id); (gdb) ^C Program received signal SIGINT, Interrupt. 0x00007ffff7bc2292 in ?? () (gdb) break 81 Breakpoint 5 at 0x55555555a9a4: file process2.cpp, line 81. (gdb) disable 4 (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /media/extradisk/src/codefudge/codefudge/datagen/process2 ../repos/Rust warning: Probes-based dynamic linker interface failed. Reverting to original interface. Loading commits for ../repos/Rust commit: a3632327e441c5975f2e40ca794111c87de80d8a Breakpoint 3, main (argc=2, argv=0x7fffffffe2e8) at process2.cpp:761 761 if (outputter.process(max_diffs_per_commit)) { (gdb) disable 3 (gdb) cont Continuing. looping over diff: a3632327e441c5975f2e40ca794111c87de80d8a Breakpoint 5, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:81 81 static thread_local std::vector<cppgit2::oid> non_remote_references; here i held "n" for a while to watch the loop continue. it was finding commits that didn't match its condition on line 90, so it just loop for a bit, and I set a breakpoint on line 91 to drill down: (gdb) list 80 { 81 static thread_local std::vector<cppgit2::oid> non_remote_references; 82 non_remote_references.clear(); 83 for ( 84 reference_iter.init(repository); 85 reference_iter; 86 ++ reference_iter 87 ) { 88 auto branch = *reference_iter; 89 auto branch_tip = branch.resolve().target(); (gdb) list 90 if (branch_tip == commit || repository.is_descendant_of(branch_tip, commit)) { 91 static thread_local std::string branch_name; 92 branch_name = branch.name(); 93 try { 94 return repository.branch_remote_name(branch_name); 95 } catch (cppgit2::git_exception &) { 96 non_remote_references.push_back(branch_tip); 97 } 98 } 99 } (gdb) break 91 Breakpoint 6 at 0x55555555ab10: file process2.cpp, line 91. (gdb) cont Continuing.
warning: Probes-based dynamic linker interface failed. Reverting to original interface.
I'm guessing the above quote is related to the following then happening. The breakpoint was not hit, so I interrupted execution to try to quickly find the outer code executing: (gdb) cont Continuing. ^C Program received signal SIGINT, Interrupt. 0x00007ffff7ed54f8 in ?? () (gdb) n Cannot find bounds of current function (gdb) Cannot find bounds of current function (gdb) ni 0x00007ffff7ed54fa in ?? () (gdb) I hit 'enter' a few times, and the instruction pointer advanced, but debugging ended up terminating for some reason when I tried to skip to the next ret, very strange: ... (gdb) 0x00007ffff7ed53e6 in ?? () (gdb) 0x00007ffff7ed53e7 in ?? () (gdb) fini Run till exit from #0 0x00007ffff7ed53e7 in ?? () free(): invalid pointer Program received signal SIGABRT, Aborted. 0x00007ffff7a7700b in ?? () so i ran "run" again to try another approach to the issue. valgrind is still chunking away.
note: if this were caused by a trojan, malware, virus, etc, it would be important to take a memory image with a 2nd system or dedicated hardware
note: one way to do that, is to suspend the system to disk, and then boot off dedicated media and extract the memory from ram remanence. this approach would fail if an attacker acted to deter it.
i am currently using this system to write this email i do not have boot media prepared, to extract either the disk or the memory i do not have a 2nd system on hand. there are also pci cards that can extract memory; they likely also need a 2nd system. this is a server i am running in the basement of a family member. this family member mentioned a second system being available recently. they are asleep.
for single systems, it would make sense to have a grub mode that produces a hashed memory dump you'd boot to the grub mode, photograph the hash, and upload the image with the photo this would not be bulletproof but would be exotic and strong enough to help
i mostly never work on security and engage systems so as to make them _less_ secure due to my brainwashing you can tell cause i don't use end to end email cryptography
i think there might be a hotkey that makes a dump on linux, something about sysrq near the concept of raising elephants
i don't see it in the list on wikipedia: although there is a key to make the system crash, which then theoretically takes a crashdump, maybe just of the kernel though. (alt- "sysrq", "c"; or somesuch) i love imaging systems and storing the images! not what's up atm though. thinking that suspending to disk, you could probably boot a certain way and make a copy of the swap partition. rescue mode maybe? i'm running linux on a macintosh. i'm not sure how the bootloader works. i don't see a grub menu on boot. i set this up following online instructions and don't remember which ones i followed.
seems it would be simplest to enable ram dumping, and just cat the ram and swap to an archive file. the ram dump could be mutated but it would still be expected to explain the behavior in some way.
valgrind is still running . at the launch of the script it has an unoptimized loop that indexes every commit. there are a lot of them. it just finished while typing this. now it is in the hang.
valgrind is not finding any errors yet, after running for some tens of seconds. given last time i was hand-stepping, this likely indicates it won't find any unless the loop terminates, changing the situation.
the code works with all offline data, so i could reduce variables, in theory, by running offline maybe i'll try to store it all
$ mkdir bins $ cp process2 bins/ $ cp $(ldd process2 | sed -ne 's!.* \(/.*\) (.*!\1!p') bins/ $ mv bins bins-$(date --iso=seconds) $ cp $(type -p gdb) bins-2022-08-07T00\:58\:57-04\:00/ $ cp $(ldd $(type -p gdb) | sed -ne 's!.* \(/.*\) (.*!\1!p') bins-2022-08-07T00\:58\:57-04\:00/ $ w3 put bins-2022-08-07T00\:58\:57-04\:00 # Packed 34 files (59.2MB) # bafybeifwhtetm3n64l4nbvqlllkzixljn6cjzouleywk3re2pianfxqdtu ⁂ Stored 34 files ⁂ https://dweb.link/ipfs/bafybeifwhtetm3n64l4nbvqlllkzixljn6cjzouleywk3re2pian... The repository I was running it on is still packing. It's over 5 gigabytes now and may be unreasonable to quickly upload.
anyway while that packs i'll resume troubleshooting the issue. i know it's likely resolvable with some simple quirky bug that i just need to find.
last time i used line 91 to break after the filter condition. that's the static assignment and could have confused gdb, because it's weird code that is run only on the first function call. i'm breaking on line 92 instead.
for now i'm putting a breakpoint on line 96 too, inside the exception handler. this lets me engage the situation in a way that doesn't freak me out, seeing that it keeps returning to the debugger without any complaints, as it goes over the references containing the commit
i'm typing "cont" to keep hitting the breakpoints, and told it to display the "branch_name" variable. it's enumerating tags that contain the commit. Continuing. Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 1: branch_name = "refs/tags/0.1.0-alpha1" (gdb) Continuing. Breakpoint 2, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:96 96 non_remote_references.push_back(branch_tip); 1: branch_name = "refs/tags/0.1.0-beta1" (gdb) Continuing. Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 1: branch_name = "refs/tags/0.1.0-beta1" (gdb) Continuing. Breakpoint 2, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:96 96 non_remote_references.push_back(branch_tip); 1: branch_name = "refs/tags/0.10.1" (gdb)
i added breakpoints on lines 100 and 413, which are control paths via which it can exit the iteration, so i can examine the state and differentiate if it exits the loop correctly. theoretically, i could hit 'cont' through every tag and see what happens. meanwhile, i've been trying to pack the source code, and w3 encountered a symbolic link loop preventing packing. it hit 6 gigabytes before it bailed O_o; very large for this source code: datagen$ w3 put . ⠙ Packing 20570 files (6349.2MB)Error: ELOOP: too many symbolic links encountered, stat '/media/extradisk/src/codefudge/codefudge/datage n/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/ti nytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crat e/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokeni zers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinyto kenizers/target/release/build/tinytokenizers-094d245b8aabc62c/out/cxxbridge/crate/tinytokenizers/target/release/build/rayon-core-8ca1c07 368254e7f/build_script_build-8ca1c07368254e7f.d' looks like it's inside my tinytokenizers hack-build to access huggingface's rust tokenizer library within c++. the code isn't presently using tokenization, at all.
⠼ Packing 13339 files (393.9MB)Error: ENOENT: no such file or directory, stat '/media/extradisk/src/codefudge/codefudge/datagen/tinytokenizers/target/cxxbridge/tinytokenizers/src/tinytokenizers.rs.cc'
the missing file is a symlink into the folder i deleted. i'll review the build file, verify i am not linking with tinytokenizers, and i suppose clean it or wipe its target directory or whatnot
it seems to be packing them fine now. it's taking a bit. 442.8MB including the submodule dependencies. i'll 'cont' a few more times and look at those tags.
so this is interesting: after refs/tags/0.10.7 it iterated for a bit without hitting a breakpoint, and then encountered refs/tags/0.10.7 _again_ Breakpoint 2, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:96 96 non_remote_references.push_back(branch_tip); 1: branch_name = "refs/tags/0.10.6" (gdb) Continuing. Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 1: branch_name = "refs/tags/0.10.6" (gdb) Continuing. Breakpoint 2, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:96 96 non_remote_references.push_back(branch_tip); 1: branch_name = "refs/tags/0.10.7" (gdb) Continuing. Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 1: branch_name = "refs/tags/0.10.7" it's great to drill down on quirks more. (gdb) list 87 ) { 88 auto branch = *reference_iter; 89 auto branch_tip = branch.resolve().target(); 90 if (branch_tip == commit || repository.is_descendant_of(branch_tip, commit)) { 91 static thread_local std::string branch_name; 92 branch_name = branch.name(); 93 try { 94 return repository.branch_remote_name(branch_name); 95 } catch (cppgit2::git_exception &) { 96 non_remote_references.push_back(branch_tip); I'm curious if the reference pointer is the same. It looks like engaging this may mean going into the source of libgit for me; uncertain. meanwhile the source code has finished packing: datagen$ rm -rf tinytokenizers/target datagen$ w3 put . # Packed 13380 files (442.8MB) # bafybeiaeshr3p2qgb6wpdstjs53inods3jkekgtowuokmt2tjdugtg3ra4 ⠧ Chunking Now it's on to "Storing", 19% .
this is the commit it happens to be looking at. theoretically, all the named refs contain this commit. this hash is one way of finding the repository containing the refs: (gdb) p commit.to_hex_string(40) $4 = "a3632327e441c5975f2e40ca794111c87de80d8a"
locally, i have a whole mess of public repositories squished together into one repo, so as to work with their commits together, and i don't yet know which one the commit came from. the function in question is of course supposed to identify that.
datagen$ w3 put . # Packed 13380 files (442.8MB) # bafybeiaeshr3p2qgb6wpdstjs53inods3jkekgtowuokmt2tjdugtg3ra4 ⁂ Stored 13380 files ⁂ https://dweb.link/ipfs/bafybeiaeshr3p2qgb6wpdstjs53inods3jkekgtowuokmt2tjdug... source upload finished. meanwhile, the repo upload has finished packing and is chunking: datagen$ w3 put ../repos/Rust # Packed 58995 files (5036.7MB) # bafybeia23j2cdkqn3pfmmc7iwsbhjmvmx4a26qaqxv3ejpwunfqa2enyg4 ⠙ Chunking
current state of debugging: I had encountered the branch name "refs/tags/0.10.7" twice in a row. i'd like to step through the libgit structures and code moving from the first one to the second, to gain information on how this happens or what it means or indicates.
(gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /media/extradisk/src/codefudge/codefudge/datagen/process2 ../repos/Rust [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Loading commits for ../repos/Rust commit: a3632327e441c5975f2e40ca794111c87de80d8a looping over diff: a3632327e441c5975f2e40ca794111c87de80d8a Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 1: branch_name = "" (gdb) n 94 return repository.branch_remote_name(branch_name); 1: branch_name = "refs/tags/0.0.0" (gdb) cont Continuing. ... Continuing. Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 1: branch_name = "refs/tags/0.10.6" (gdb) Continuing. Breakpoint 2, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:96 96 non_remote_references.push_back(branch_tip); 1: branch_name = "refs/tags/0.10.7"
(gdb) p branch $6 = {<cppgit2::libgit2_api> = {<No data fields>}, c_ptr_ = 0x5555562f5d60, owner_ = cppgit2::ownership::libgit2} (gdb) p *branch.c_ptr_ $7 = {db = 0x5555557b4aa0, type = GIT_REFERENCE_DIRECT, target = {oid = {id = "\030O\035\237\262\351jy\207A¾\327\306?X\v\357$\020"}, symbolic = 0x796ae9b29f1d4f18 <error: Cannot access memory at address 0x796ae9b29f1d4f18>}, peel = { id = '\000' <repeats 19 times>}, name = 0x5555562f5d9c "refs/tags/0.10.7"} this all looks right to me
here i am about to step into the iterator to find the next one: (gdb) n 95 } catch (cppgit2::git_exception &) { (gdb) n 89 auto branch_tip = branch.resolve().target(); (gdb) n 88 auto branch = *reference_iter; (gdb) n 86 ++ reference_iter i infer it engaged some scope destructors before getting there.
86 ++ reference_iter 1: branch_name = "refs/tags/0.10.7" (gdb) s repo_commits::reference_iterator::operator++ (this=0x5555555ac508) at process2.cpp:253 253 if (git_reference_next(&c_ref, c_ptr) != 0) { 1: branch_name = "refs/tags/0.10.7" (gdb) s git_reference_next (out=0x5555555ac510, iter=0x555557fb0ec0) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/refs.c:762 762 return git_refdb_iterator_next(out, iter); 1: branch_name = "refs/tags/0.10.7" Bravely, my debugger prepares to blaze a path into libgit!
success. my undisplay call did not work. (gdb) undisplay branch_name (gdb) si git_refdb_iterator_next (out=0x5555555ac510, iter=0x555557fb0ec0) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/refdb.c:219 219 { 1: branch_name = "refs/tags/0.10.7" (gdb) list 214 215 return 0; 216 } 217 218 int git_refdb_iterator_next(git_reference **out, git_reference_iterator *iter) 219 { 220 int error; 221 222 if ((error = iter->next(out, iter)) < 0) 223 return error;
turns out the syntax is "undisplay 1". i accidentally stepped over the next call, so i'm redoing it to get back to the same state.
reminder to self: the tag in quesiton is 0.10.7, and the goal is to step into libgit, then step into iter->next . the data structure is likely a linked list, so it would be good to inspect it before it is advanced, so the two parts might be visible side by side
i added another display for branch_name, it's #3 now. 222 if ((error = iter->next(out, iter)) < 0) 3: branch_name = "refs/tags/0.10.7" (gdb) s refdb_fs_backend__iterator_next (out=0x5555555ac510, _iter=0x555557fb0ec0) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/refdb_fs.c:874 874 { 3: branch_name = "refs/tags/0.10.7" (gdb) list 869 return error; 870 } 871 872 static int refdb_fs_backend__iterator_next( 873 git_reference **out, git_reference_iterator *_iter) 874 { 875 int error = GIT_ITEROVER; 876 refdb_fs_iter *iter = GIT_CONTAINER_OF(_iter, refdb_fs_iter, parent); 877 refdb_fs_backend *backend = GIT_CONTAINER_OF(iter->parent.db->backend, refdb_fs_backend, parent); 878 struct packref *ref; (gdb) list 879 880 while (iter->loose_pos < iter->loose.length) { 881 const char *path = git_vector_get(&iter->loose, iter->loose_pos++); 882 883 if (loose_lookup(out, backend, path) == 0) { 884 ref = git_sortedcache_lookup(iter->cache, path); 885 if (ref) 886 ref->flags |= PACKREF_SHADOWED; 887 888 return 0;
(gdb) n 877 refdb_fs_backend *backend = GIT_CONTAINER_OF(iter->parent.db->backend, refdb_fs_backend, parent); 3: branch_name = "refs/tags/0.10.7" (gdb) undisplay 3 (gdb) n 880 while (iter->loose_pos < iter->loose.length) { (gdb) p (*iter) $12 = {parent = {db = 0x5555557b4aa0, next = 0x7ffff7ebbba0 <refdb_fs_backend__iterator_next>, next_name = 0x7ffff7ebbaa0 <refdb_fs_backend__iterator_next_name>, free = 0x7ffff7eba8c0 <refdb_fs_backend__iterator_free>}, glob = 0x0, pool = {pages = 0x555555e01f40, item_size = 1, page_size = 4056}, loose = {_alloc_size = 3444, _cmp = 0x0, contents = 0x555557191dd0, length = 2315, flags = 0}, cache = 0x555557fb17d0, loose_pos = 1222, packed_pos = 0} (gdb) n 881 const char *path = git_vector_get(&iter->loose, iter->loose_pos++); (gdb) n 883 if (loose_lookup(out, backend, path) == 0) { (gdb) p path $13 = <optimized out> i'm using an optimized libgit, so i'll set it rebuilding unoptimized to make debugging easier when it finishes
- i already have the unoptimized build made and just need to rebuild using it - git_vector_get is a macro, but the data structure is not complex: (gdb) p git_vector_get(&iter->loose, iter->loose_pos) No symbol "git_vector_get" in current context. (gdb) p iter->loose $14 = {_alloc_size = 3444, _cmp = 0x0, contents = 0x555557191dd0, length = 2315, flags = 0} (gdb) p iter->loose.contents $15 = (void **) 0x555557191dd0 (gdb) p iter->loose.contents[iter->loose_pos] $16 = (void *) 0x555555780e00 (gdb) p (char*)iter->loose.contents[iter->loose_pos] $17 = 0x555555780e00 "refs/tags/0.11.0"
it looks as if the loose_pos element of the iterator might not have been being incremented: (gdb) p (char*)iter->loose.contents[iter->loose_pos-1] $18 = 0x555555780de8 "refs/tags/0.10.7" (gdb) p (char*)iter->loose.contents[iter->loose_pos-2] $19 = 0x555555780dd0 "refs/tags/0.10.6" i can review the behavior running to see whether this variable is being decremented, resulting in a repeat 0.10.7 . i should start with the first iteration that hits 0.10.7, as it seems that is when the incrementation happens.
here's 0.10.6 again. i'll step into the iteration: Breakpoint 2, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:96 96 non_remote_references.push_back(branch_tip); 4: branch_name = "refs/tags/0.10.6" (gdb)
here i am in refdb_fs_backend__iterator_next after hitting "n" to the incrementation and then "s" repeatedly. [humorously?] the branch_name is somehow still showing, even though it is out of scope and across two dynamic libraries. (gdb) refdb_fs_backend__iterator_next (out=0x5555555ac510, _iter=0x555557fb0ec0) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/refdb_fs.c:875 875 int error = GIT_ITEROVER; 4: branch_name = "refs/tags/0.10.6"
here it is about to access 0.10.7 . i'm planning to watch the loose_pos variable across the next iteration. (gdb) n 880 while (iter->loose_pos < iter->loose.length) { (gdb) n 881 const char *path = git_vector_get(&iter->loose, iter->loose_pos++); (gdb) p iter->loose_pos $20 = 1221 (gdb) p (char*)iter->loose.contents[1221] $21 = 0x555555780de8 "refs/tags/0.10.7"
it leaves the c list iterator with loose_pos incremented: (gdb) n 883 if (loose_lookup(out, backend, path) == 0) { (gdb) display iter->loose_pos 5: iter->loose_pos = 1222 (gdb) n 884 ref = git_sortedcache_lookup(iter->cache, path); 5: iter->loose_pos = 1222 (gdb) n 885 if (ref) 5: iter->loose_pos = 1222 (gdb) n 888 return 0; 5: iter->loose_pos = 1222 i'll capture loose_pos's address so i can watch it from other frames.
(gdb) p (char*)iter->loose.contents[1222] $23 = 0x555555780e00 "refs/tags/0.11.0" (gdb) p &iter->loose_pos $24 = (size_t *) 0x555557fb0f30 (gdb) undisplay 5 (gdb) display *(size_t *) 0x555557fb0f30 6: *(size_t *) 0x555557fb0f30 = 1222 now it'll show what that value is as i do everything else, anywhere in the program
here it is re-acquiring the name of 0.10.7 (#1221) while loose_pos is still prepared to return 0.11.0 as the next one: Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 6: *(size_t *) 0x555557fb0f30 = 1222 (gdb) n 94 return repository.branch_remote_name(branch_name); 6: *(size_t *) 0x555557fb0f30 = 1222 (gdb) p branch_name $25 = "refs/tags/0.10.7"
here we are about to enter the next iteration. i'm betting that it goes to 0.11.0 correctly this time. (gdb) n 86 ++ reference_iter 6: *(size_t *) 0x555557fb0f30 = 1222
(as a reminder, which i just experienced, the return statement's call to branch_remote_name throws an exception, and the iteration continues without returning)
here it is inside the c iterator, about to extract 0.11.0, after what i believe was the first iteration over 0.10.7 . maybe the quirk is explained by me not fully understanding how it works here. (gdb) n 881 const char *path = git_vector_get(&iter->loose, iter->loose_pos++); 6: *(size_t *) 0x555557fb0f30 = 1222 (gdb) p (char*)iter->loose.contents[1222] $26 = 0x555555780e00 "refs/tags/0.11.0"
_okay_, so i hit "n" through the use of that, no corruptions, nothing weird. 0.11.0 didn't match the filter, so the branch name was never pulled out of it. the commit is apparently in 0.10.7 but not in 0.11.0 . here's the log of me stepping over the lines for completeness. hope i pasted this right, a little hard. (gdb) n 881 const char *path = git_vector_get(&iter->loose, iter->loose_pos++); 6: *(size_t *) 0x555557fb0f30 = 1222 (gdb) p (char*)iter->loose.contents[1222] $26 = 0x555555780e00 "refs/tags/0.11.0" (gdb) n 883 if (loose_lookup(out, backend, path) == 0) { 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) n 884 ref = git_sortedcache_lookup(iter->cache, path); 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 885 if (ref) 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 888 return 0; 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 911 } 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) git_refdb_iterator_next (out=0x5555555ac510, iter=0x555557fb0ec0) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/refdb.c:225 225 GIT_REFCOUNT_INC(iter->db); 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 226 (*out)->db = iter->db; 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 228 return 0; 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 229 } 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) git_reference_next (out=0x5555555ac510, iter=0x555557fb0ec0) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/refs.c:763 763 } 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) repo_commits::reference_iterator::operator++ (this=0x5555555ac508) at process2.cpp:256 256 } 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:83 83 for ( 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 85 reference_iter; 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 88 auto branch = *reference_iter; 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 89 auto branch_tip = branch.resolve().target(); 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 90 if (branch_tip == commit || repository.is_descendant_of(branch_tip, commit)) { 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 89 auto branch_tip = branch.resolve().target(); 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 88 auto branch = *reference_iter; 6: *(size_t *) 0x555557fb0f30 = 1223 (gdb) 86 ++ reference_iter 6: *(size_t *) 0x555557fb0f30 = 1223
i added branch.name() to display, and everything looks fine as the tags go forward. the commit isn't in any of the later tags yet. i hit continue for the next breakpoint, and got different output than what i thought i got last time. it's moved to a further tag, rather than returning to 0.10.7 : Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 6: *(size_t *) 0x555557fb0f30 = 1300 7: branch.name() = "refs/tags/0.3.0-alpha.1" (gdb)
kinda frustrating to have my memory of what happened be different from what is happening now, when i'm not aware of having changed anything now that i think about it, i did change something: i installed a debugging version of libgit2. I figured this wouldn't matter, since i didn't relink process2, but since it is a shared library, the new code must be being loaded rather than the old.
i'm stepping through the matching refs to see if the code succeeds with the debugging library loaded. i'm up to pos 2108. there are a lot of matching refs. the current code accumulates refs that aren't branches and then finds how to get their data after the accumulation. i'm realising it could run a lot faster if it searched fro them when it found them, rather than accumulating them.
it found a remote containing this data at pos 2314 (next pos 2315): Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 6: *(size_t *) 0x555557fb0f30 = 2315 7: branch.name() = "refs/tags/vv0.3.5" (gdb) Continuing. Breakpoint 2, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:96 96 non_remote_references.push_back(branch_tip); 6: *(size_t *) 0x555557fb0f30 = 2315 7: branch.name() = "refs/tags/vv0.3.5" (gdb) Continuing. Breakpoint 1, repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:92 92 branch_name = branch.name(); 6: *(size_t *) 0x555557fb0f30 = 2315 7: branch.name() = "refs/remotes/Wiggin-Labs_minerva.git/ir" (gdb) Continuing. i'm not sure why the pos hasn't incremented in the last breakpoint. after the final "cont", it is just hanging there. i thought i had set a breakpoint after the return, but maybe i had not.
pleasantly, interrupting it shows code this time. i'm curious where it is hanging: ^C Program received signal SIGINT, Interrupt. 0x00007ffff7dcdd42 in git_config_entries_dup (out=0x7fffffffd7d8, entries=0x555557159b10) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/config_entries.c:90 90 if ((git_config_entries_dup_entry(result, head->entry)) < 0) 6: *(size_t *) 0x555557fb0f30 = 2315 (gdb) bt #0 0x00007ffff7dcdd42 in git_config_entries_dup (out=0x7fffffffd7d8, entries=0x555557159b10) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/config_entries.c:90 #1 0x00007ffff7dd2d68 in config_snapshot_iterator (iter=0x555557b997e0, backend=0x555557f29380) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/config_snapshot.c:34 #2 0x00007ffff7dcab91 in all_iter_next (entry=0x7fffffffd8c0, _iter=0x555557b997c0) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/config.c:400 #3 0x00007ffff7dcc3a4 in multivar_iter_next (entry=0x7fffffffd8c0, _iter=0x555555dc9d00) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/config.c:1032 #4 0x00007ffff7dcc2aa in git_config_get_multivar_foreach (cfg=0x555556da1f10, name=0x555557cc2130 "remote.TopologicallySpeaking_ckproof.git.push", regexp=0x0, cb=0x7ffff7e5c591 <refspec_cb>, payload=0x7fffffffd970) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/config.c:1000 #5 0x00007ffff7e5c648 in get_optional_config (found=0x0, config=0x555556da1f10, buf=0x7fffffffd980, cb=0x7ffff7e5c591 <refspec_cb>, payload=0x7fffffffd970) at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/remote.c:443 #6 0x00007ffff7e5cb8d in git_remote_lookup (out=0x7fffffffd9e0, repo=0x5555555ac770, name=0x5555577e7620 "TopologicallySpeaking_ckproof.git") at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/remote.c:545 #7 0x00007ffff7db7519 in git_branch__remote_name (out=0x7fffffffda60, repo=0x5555555ac770, refname=0x555557f76a00 "refs/remotes/Wiggin-Labs_minerva.git/ir") at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/branch.c:576 #8 0x00007ffff7db7369 in git_branch_remote_name (out=0x7fffffffdab0, repo=0x5555555ac770, refname=0x555557f76a00 "refs/remotes/Wiggin-Labs_minerva.git/ir") at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/ext/libgit2/src/branch.c:543 #9 0x00007ffff7f6f719 in cppgit2::repository::branch_remote_name (this=0x5555555ac498, refname="refs/remotes/Wiggin-Labs_minerva.git/ir") at /media/extradisk/src/codefudge/codefudge/datagen/bold84-cppgit2/src/repository.cpp:656 #10 0x000055555555abe5 in repo_commits::remote_name[abi:cxx11](cppgit2::oid const&) (this=0x5555555ac478, commit=...) at process2.cpp:94 #11 0x000055555555ce3e in output_manager::process (this=0x7ffff7420c68, max_diffs_per_commit=1) at process2.cpp:412 #12 0x0000555555559630 in main (argc=2, argv=0x7fffffffe2c8) at process2.cpp:763
[ the hanging call is 0x00007ffff7db7519 in git_branch__remote_name (out=0x7fffffffda60, repo=0x5555555ac770, refname=0x555557f76a00 "refs/remotes/Wiggin-Labs_minerva.git/ir") which i found by typing 'fini' and 'fin' until it hung again. this is a different slowdown, the git branch remote lookup; i can isolate this in my output by adding a logging statement prior to it. ]
not actually immediately easy to isolate. forgot i had moved this code so that nonremote branches are handled with an exception. not sure why this call is going so slowly all of a sudden.
basically i should be checking whether the reference is a remote using its getter to do so, rather than handling an exception.
given it is slow to match remote branches to remotes, i should enumerate them all at the start, since the lookup could happen a lot
i'm changing it to enumerate the remote fetchspecs at the start. i'm confused by a compilation error: cppgit2::remote remote = repository.lookup_remote(remote_name); cppgit2::refspec fetchspec = cppgit2::refspec::parse(remote.fetchspec(), true); The error is on the second line, regarding remote.fetchspec(): (6 of 10): error: ‘class cppgit2::remote’ has no member named ‘fetchspec’; did you mean ‘fetch_’? I formed the call from the source of a file named remote.hpp in the cppgit2 sources: // Fetchspec std::string fetchspec() const { return c_ptr_->fetchspec ? std::string(c_ptr_->fetchspec) : ""; } Usually when this happens it is because I am referencing a different class than I am using, I would guess.
yep, this is a nested class called 'create_options'. that's why fetchspec is (i presume, hard to tell the number of spaces) indented by 4 spaces rather than 2. class create_options : public libgit2_api { public:
// Get the remote's list of fetch refspecs // The memory is owned by the user and should be freed strarray fetch_refspec() const;
i have built a version that may run faster. encountered this at first attempt to test: (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y `/media/extradisk/src/codefudge/codefudge/datagen/process2' has changed; re-reading symbols. /build/gdb-ktlO15/gdb-9.2/gdb/gdbtypes.c:4981: internal-error: type* copy_type_recursive(objfile*, type*, htab_t): Assertion `TYPE_OBJFILE (type) == objfile' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n)
gdb says it dumped core but i'm not sure where the core file is yet, nothing new that i see in cwd
Quit this debugging session? (y or n) y This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. /build/gdb-ktlO15/gdb-9.2/gdb/gdbtypes.c:4981: internal-error: type* copy_type_recursive(objfile*, type*, htab_t): Assertion `TYPE_OBJFILE (type) == objfile' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Aborted (core dumped) $ sudo chmod 644 /var/crash/* $ w3 put /var/crash # Packed 9 files (58.6MB) # bafybeidsnxx34eglnudnxrlucohueacign4yzp7atd5es2i4p7m5cjloca ⁂ Stored 9 files ⁂ https://dweb.link/ipfs/bafybeidsnxx34eglnudnxrlucohueacign4yzp7atd5es2i4p7m5... $ ls -l /var/crash total 59980 -rw-r--r-- 1 root whoopsie 278015 Aug 4 06:16 nvidia-kernel-common-515.0.crash -rw-r--r-- 1 user whoopsie 124530 Jul 31 12:33 _usr_bin_asciinema.1000.crash -rw-r--r-- 1 user whoopsie 0 Jul 31 12:33 _usr_bin_asciinema.1000.upload -rw-r--r-- 1 user whoopsie 14242801 Aug 3 06:28 _usr_bin_gdb.1000.crash -rw-r--r-- 1 user whoopsie 0 Aug 3 06:28 _usr_bin_gdb.1000.upload -rw-r--r-- 1 user whoopsie 695246 Aug 4 08:17 _usr_lib_git-core_git.1000.crash -rw-r--r-- 1 user whoopsie 0 Aug 4 08:17 _usr_lib_git-core_git.1000.upload -rw-r--r-- 1 user whoopsie 46071279 Aug 1 07:10 _usr_lib_x86_64-linux-gnu_valgrind_memcheck-amd64-linux.1000.crash -rw-r--r-- 1 user whoopsie 0 Aug 1 07:10 _usr_lib_x86_64-linux-gnu_valgrind_memcheck-amd64-linux.1000.upload
unfortunately today is august 7th i don't know where this gdb core file is if it exists sounds like a further bug in something, possibly
$ cat /proc/sys/kernel/core_pattern |/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E
i implemented optimizations that seemed to work well. the big remaining one is the enumeration of commits at the start. i started debugging it, but ran into issues again. i might need either a local build of gdb or some more carefulness or something: Breakpoint 1, repo_commits::repo_commits (path=<optimized out>, this=<optimized out>) at process2.cpp:75 75 auto revwalk = repository.create_revwalk(); (gdb) s main (argc=2, argv=0x7fffffffe2e8) at process2.cpp:787 787 possible_conflicts = repository.merge_commits(commit.parent(0), commit.parent(1)); the source line it's on keeps jumping around, epecially in the area i want to debug. most recently it seemed gdb typed a bunch of things in on its own, completely changing where it was and what it was doing. meanwhile my system has begun responding at a snails pace, this email taking minutes to slowly process each letter.
looks like i had just failed to rebuild for debugging mode. for the mysterious gdb behavior, i'm considering i may have dissociated, lost time, and tricked myself into thinking the keystrokes happened on their own the computer is responding much faster now too
ok, it seems pretty clear i installed the debugging libraries and built the binary in debug mode. i'm still not getting source lines inside cppgit2 codefudge/datagen/bold84-cppgit2/build.debug$ grep CMAKE_BUILD_TYPE CMakeCache.txt CMAKE_BUILD_TYPE:STRING=Debug in the scrollback history i have installing it, although maybe i forgot to delete the old files. i'm planning to reinstall. $ cat install_manifest.txt | sudo xargs rm $ sudo make install -j
codefudge/datagen$ make clean process2 rm process2 g++ -ggdb -O0 process2.cpp -lcppgit2 -lgit2 -o process2
$ ldd process2 linux-vdso.so.1 (0x00007ffdedfe9000) libcppgit2.so.1 => /usr/local/lib/libcppgit2.so.1 (0x00007f163bc82000) libgit2.so.1.4 => /usr/local/lib/libgit2.so.1.4 (0x00007f163baf6000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f163b914000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f163b8f9000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f163b707000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f163b6e4000) libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f163b64f000) libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f163b379000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f163b306000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f163b2ea000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f163b19b000) /lib64/ld-linux-x86-64.so.2 (0x00007f163bd62000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f163b195000) codefudge/datagen$ sha256sum /usr/local/lib/lib*git2* bold84-cppgit2/build.debug/lib/lib*git2* a758f000a4c60aa9ca89e0303bf80dfb473361c7aaf0cc2d0f765d77c27b8e52 /usr/local/lib/libcppgit2.so a758f000a4c60aa9ca89e0303bf80dfb473361c7aaf0cc2d0f765d77c27b8e52 /usr/local/lib/libcppgit2.so.0.1.0 a758f000a4c60aa9ca89e0303bf80dfb473361c7aaf0cc2d0f765d77c27b8e52 /usr/local/lib/libcppgit2.so.1 c8eed2c494aad8a2f0c41e71aa7640ff7a48d08816b9c8e3062256c88425d55e /usr/local/lib/libgit2.so c8eed2c494aad8a2f0c41e71aa7640ff7a48d08816b9c8e3062256c88425d55e /usr/local/lib/libgit2.so.1.4 c8eed2c494aad8a2f0c41e71aa7640ff7a48d08816b9c8e3062256c88425d55e /usr/local/lib/libgit2.so.1.4.0 fd69ee76e0bf957245a635f0d8afde211710e31ef3ea4f8ef7facff1fcbe12b0 bold84-cppgit2/build.debug/lib/libcppgit2.so fd69ee76e0bf957245a635f0d8afde211710e31ef3ea4f8ef7facff1fcbe12b0 bold84-cppgit2/build.debug/lib/libcppgit2.so.0.1.0 fd69ee76e0bf957245a635f0d8afde211710e31ef3ea4f8ef7facff1fcbe12b0 bold84-cppgit2/build.debug/lib/libcppgit2.so.1 327c6e9ac5d9bf5afaffc74ec18522c0c810dd81e1b4f23c81ffa2a876f4ba36 bold84-cppgit2/build.debug/lib/libgit2.pc c8eed2c494aad8a2f0c41e71aa7640ff7a48d08816b9c8e3062256c88425d55e bold84-cppgit2/build.debug/lib/libgit2.so c8eed2c494aad8a2f0c41e71aa7640ff7a48d08816b9c8e3062256c88425d55e bold84-cppgit2/build.debug/lib/libgit2.so.1.4 c8eed2c494aad8a2f0c41e71aa7640ff7a48d08816b9c8e3062256c88425d55e bold84-cppgit2/build.debug/lib/libgit2.so.1.4.0 33b1352b09459028f5c94c7b047edb8a3c8b963516db029f78ddfdf6e553eead bold84-cppgit2/build.debug/lib/libgit2_tests
looks like there's a different libcppgit2.so than in the debug tree, despite my make install comparatively, the libgit2's are the same. it would explain the situation if libcppgit2 were missing from install_manifest or maybe some error prevented deletion of them
maybe this is why the checksums of the installed vs built debug libraries differs: -- Installing: /usr/local/lib/libcppgit2.so.0.1.0 -- Installing: /usr/local/lib/libcppgit2.so.1 -- Set runtime path of "/usr/local/lib/libcppgit2.so.0.1.0" to "" -- Installing: /usr/local/lib/libcppgit2.so The runtime path is likely a constant stored in the binary. Changing it would change the sha256sum. libgit2's runtime path is not changed.
after reinstalling this time, i can now step into the dependency code successfully . I'm not aware of having changed anything.
an extant concern is this: Loading commits for ../repos/NWScript/ commit: a7278603f354eb683296f443e49621e50d35fcf0 looping over diff: a7278603f354eb683296f443e49621e50d35fcf0 process2: /usr/include/rapidjson/internal/stack.h:129: T* rapidjson::internal::Stack<Allocator>::PushUnsafe(std::size_t) [with T = char; Allocator = rapidjson::CrtAllocator; std::size_t = long unsigned int]: Assertion `stackTop_ + sizeof(T) * count <= stackEnd_' failed. xargs: ./process2: terminated by signal 6 I got the error just trying to run the code on all the data some hours ago. When I reran the code on only that repository, it enumerated all the commits, despite the trees being very very large, and did not crash at all. I'm currently running it in valgrind to see if there's anything to catch. This is my test commandline: shuf --echo ../repos/*/ --zero-terminated | xargs -0 ./process2 | tee test.json | cut -c1-160 I use zero termination because some of the repo paths (each one is named after a code language, and collects many remotes together written in that language) have spaces in them, which xargs doesn't handle well. It would be helpful to get shuf behaving deterministically. A simple approach would be to cache its output in a file.
I'm guessing that the rapidjson error simply means the input data is unexpectedly larger than the stack space.
But maybe I have a memory leak ! That sounds interesting. Resuming reviewing the commit enumeration code.
how libgit revwalk works: - when initialised with a glob, it iterates all the refs that match the glob and forwards to the procedure that initialises with refs - initialising with refs converts the refs to a name, then to a direct oid, and hands off to the procedure that initialises with commits - it looks like the commit initialisation code (just quickly looking at) likely retains a set of commit objects, and inserts each one to the set, such that adding a commit twice would be a no-op. not certain. the oidmap is stored in walk->commits. (gdb) p commit $5 = (git_commit_list_node *) 0x555555827308 (gdb) p *commit $6 = {oid = {id = "B&\352\071\273\306Ν@\367:\005|O\201H\230\276ʲ"}, time = 0, generation = 0, seen = 0, uninteresting = 0, topo_delay = 0, parsed = 0, added = 0, flags = 0, in_degree = 0, out_degree = 0, parents = 0x0} the "uninteresting" flag appears to be used to hide commits, as if they are not in the list. - there are functions called to perform by commit date Iterating every reference and matching them to a wildcard glob takes some time here. I'm imagining making this faster by enumerating just the references, remotes, branches or such. Ideally remotes, since this maps better to individual projects and codebases: but since so many tags contain orphaned code, it could make sense to instead enumerate all references, not sure. If the remote enumeration code could be combined without too much delay, then nonrepetition of remotes could be included. - when the first item is iterated from the revwalk, it performs initial parsing. there is a commit graph file it uses. - if a commit is uninteresting, it appears to mark all its parents as uninteresting - commits are tracked whether they have been seen already or not. new commits are added to the commit list. this initialisation is in prepare_walk in libgit2/src/revwalk.c:617 or so - when the revwalk is enumerated, commits are popped off the list and returned. each popped commit has its parents added back to the list, to enumerate them. that seems to be the guts of it. it's what you'd expect, but looking at the internals helps me plan how to use them differently much more easily. for example, i did not know there were functions to add references or commit oids, rather than globs.
note: to track nonrepetition in the commit list, the same list node structure that represents every commit is used with its seen flag.
On 8/7/22, punk <punks@tfwno.gf> wrote:
On Sun, 7 Aug 2022 05:31:31 -0400 "Undiscussed Groomed for Male Slavery, One Victim of Many" <gmkarl+brainwashingandfuckingupthehackerslaves@gmail.com> wrote:
motherfucking piece of jewnazi spammer 'karl' changed his address - filter updated.
ps: best thing would be to ban this scumbag.
i guess i could think about banning him, it could offer everyone some protection; could you remind me of how? what would i select for the event showing why?
On Sun, 7 Aug 2022 05:31:31 -0400 "Undiscussed Groomed for Male Slavery, One Victim of Many" <gmkarl+brainwashingandfuckingupthehackerslaves@gmail.com> wrote: motherfucking piece of jewnazi spammer 'karl' changed his address - filter updated. ps: best thing would be to ban this scumbag.
participants (4)
-
punk -
Undiscussed Groomed for Male Slavery, One Victim of Many -
Undiscussed Groomed for Male Slavery, One Victim of Many -
Undiscussed Past Horrific Abuse, One Victim Of Many