[spam][personal][crazy] Trying to Build Bitcoin from Source
Bitcoin is like using the blood of the devil to escape hell. It's a very powerful reagent but produces strange things around you, like fires and torture, and your chemotherapist may have bad things to tell you about your soul. Or wait, is that something else that does that, other than cryptocurrency? Maybe telling people what you're doing on the internet? Anyway, I'll try more to build bitcoin. It's 15:17 EDT and I'm booting up a terminal in X. Okay, I've got my tmux session loaded. The current issue that when i run bitcoind, it throws an allocation error trying to allocate a randomly huge number of bytes long string, inside boost::filesystem. I've just built boost with debug-symbols=on to see if I can find the problem. It's 15:20 EDT. I'm installing a locally built version of boost 77. I recall I already tried this, and that gcc shows no debug symbols, dunno. Right now my install command is for some reason trying to rebuild everything that was just built. I guess I'll let it finish configuring and see if it gets anywhere. It's 15:21 and i just restarted my boost configuration. BLARGH! This is an expression. it goes "blargh". It means "things are happy and joyous in the world I am imagining. Wouldn't you like things to be this way outside imagination?" [added later, see below: part of me thought this was maybe a bad idea to share, maybe skip it, uncertain:]It was pretty hard the past two days to do that libusb thing, and left me in a new state of mind.[end of maybe-bad-idea-to-share, tagging added later, see below] Ok. Boost intsalled. I'll quick try the debug thing again, then look for the libraries that are missing debug symbols, and troubleshoot why. 15:23 . My bits are saying it is inappropriate to share the "It was pretty hard the past ..." . It's 15:24 . The reason I write every tiny thing is because I was brainwashed to never tell anybody about what happened to me, or how, or store any evidence about it, or log experiences that help me understand it, or process it, or put an eeg on my head, or talk to doctors about my issues, or store records of what i do or what others say to me, etc etc etc etc. So, I have spent the past 8 years beating my well-helmeted head against a wall in attempts to preserve the most basic information about my life in order to live it at all, and have suffered extreme memory issues as my worse dissociated parts have struggled to stop this from happening ... and it is thus a huge celebration whenever some shred of information of my thought processes can be preserved in some kind of vaguely temporary record for more than 30 seconds. So, maybe the share was a bad idea, I dunno, every feeling-bit has its own wisdom. I'll go up and mark it that. [goes up and does this, it's 15:26] [i'm back, it's 15:27]. One project I'd really enjoy would be hacking a vnc-like thing to replay desktop sessions. That'd be nice. One of my parts is hitting me harder due to my desire to preserve even dangerous information. It's 15:27 and my gdb is not pausing when the exception I want to debug is thrown. In fact, it is producing a different error that I resolved earlier. Maybe I made an error building boost. It's 15:28 and i have two things that are logically simple and psychologically very difficult, to debug! Here's a monologue: meanie: karl, you are trying to preserve information, you know this is evil, we will now torture you defender: karl is good. you are bad. do not hurt him. hurting is bad. preserving is good. meanie: let me help you out a little bit. okay, technically preserving is _logically_ considered good, and hurting _logically_ considered bad, but karl and i have a relationship where occasionally i hurt him when he preserves information. defender: get back here and help us try to preserve stuff! is bitcoin a good way to do that? i dunno, but i'm trying to compile bitcoin right now. maybe this would be easier in a chroot of a system similar to one the devs use. meanie: please use the binary. mostly because it makes this faster, and because it helps me know i have another avenue to compromise your client with in ways that are hard to debug. but honestly, using the binary is so much faster and easier. karl: i probably don't have a compatible glibc for the binary, but it is another avenue, although i hear it might be more dangerous, not sure. meanie: all the hackers are gone, why are you here karl: i think i'm here because you were scared i might come here on my own, and wanted ot make sure you were in charge of it, not sure meanie: cypherpunks list? oh. right. kill all the hacktivists. death to hacktivists! karl: exactly! meanie: death to hacktivists? that can't be right. is this a trick? we're trying to build bitcoin, but instead typing random things obsessively. things that aren't random, but are very strange for a mailing list. so this new old issue (it's 15:32) .... um .... i don't expect it to happen because it is resolved by a preprocessor symbol that is correctly being defined. # ./b2 define=BOOST_FILESYSTEM_DISABLE_STATX debug-symbols=on install maybe i'll try "clean install" buuuuuuut that could take a long time, during which i could forget i'm doing this hmm. 15:34 . i'll re-debug the statx issue. i've come back to this email without reason, when i am trying to debug an issue on my computer. i'll send the email and use the browser without plan. it's 15:34
Bitcoin usually builds fine, building current boost and other libs take up the most time.
it's 15:41 i'll look for checks for the define BOOST_FILESYSTEM_DISABLE_STATX in the boost source code 15:41 grep -r is doing its thing more slowly than i expect. my sense of how big boost is adjusting. 15:43 it's finding hits inside binary files. hasn't gotten to the source folders yet. most linuxy terminaly softwarey people have a huge set of scripts they use to make their terminals exactly how they want. i'm not that great at keeping track of things, so i only have a couple. the one i want to talk about i have already talked about. a better use of time might be speeding up this grep. since the define is in the filesystem lib -- oops it found it! 15:44 libs/filesystem/src/operations.cpp i'm having trouble finding symbols to isolate the presence of this define by looking at object file contents. it's 15:48 BOOST_FILESYSTEM_USE_STATX is defined only if BOOST_FILESYSTEM_DISABLE_STATX is _not_ it also checks BOOST_FILESYSTEM_HAS_STATX and BOOST_FILESYSTEM_HAS_STATX_SYSCALL . maybe i'll see if other files in this folder reference the define. seems to be the only C source that references it here. 15:51 . basically functions like equivalent_stat take a struct statx if statx is enabled, a struct stat if it isn't. i guess i can check the sigs of those funcs. 15:52 objdump -t | c++filt ooooh equivalent_stat is inlined. so are the other guys. hrm. well, it looks like calls to invoke_statx only happen if it's enabled. ... but it's also inline. but it calls the real statx function! so i can check for that maybe. i could also consider wondering why this compiles at all on my system, or just mutate my stdlib headers. so it uses statx, statx_ptr, statx_fstat, some combination of those. 15:56 | grep statx yields no symbols. maybe i'll check bitcoind's symbols. ooooh i should check the filesystm library's symbols. let's check this gdb output again 1601 . the debugging flow is jumping between line numbers unexpectedly. maybe i'll delete just this object file and rebuild without optimization. oh ... except this is inside boost and that means a different library dir and name by defualt ... ummmmmmmmmmmm well i'll try linking to the debug libs. 1602 looking up on the dangerwebs how to link to boost when it's built debug. 1605 i might be able to just install the debug libs with variant=debug install but when i do this it appears to try to rebuild everything, unsure. nope! ... but it doesn't install anything either. okay. i think i figured it out. 1610 re-con-fig-ur-ing bitcoind. then i can relink it. relinking! make does more reconfiguring. doopty-doo. 16:11. it didn't relink it. _deletes binary_ relinking ...... i see it passing the flags i requested. i guess i'll just try debugging it and see if it looks better. it's 16:22 and i'm stpoped at a breakpoint in boost in bitcoin. i didn't set the LD_LIBRARY_PATH and it loaded the system libraries, not the dbeug ones =/ relaunch yay using the local libs now. 1614 uhhh there's no debugging info. at least, line numbers aren't showing. ok, it got me somewhere there are line numbers. 1614 it's jumping lines just like before =S i'll check the call it's jumping oh ok. it's doing a null pointer dereference?. no. it's not. it's skipping a call to mkdir, going straight into the calls producing the arguments. time to disassemble! here's where i have it paused right now. it's 1617: 0x00007ffff7f85333 <+99>: jne 0x7ffff7f853e0 <_ZN5boost10filesystem6detail16create_directoryERKNS0_4pathEPS3_PNS_6system10error_codeE+272> => 0x00007ffff7f85339 <+105>: mov 0x0(%rbp),%rdi 0x00007ffff7f8533d <+109>: call 0x7ffff7f7b220 <mkdir@plt> i'll step over that mkdir call and see what happens. this is boost::filesystem::detail::create_directory(boost::filesystem::path const&, boost::filesystem::path const*, boost::system::error_code*) in boost 77 . aw man my git-built gdb automatically displays the assembler when you step by instruction, really nice oh whoops my eyes are crossed. no, this is the random sourceline that has the unrelated information. it's a call to c_str within a path structure. i'll just keep typing disas. mkdir returned -1 into $eax here's what gdb shows me, classic gdb: (gdb) ni 0x00007ffff7f85342 475 const value_type* c_str() const BOOST_NOEXCEPT { return m_pathname.c_str(); } no mkdir call on that line due to optimization i guess i'll look up mkdir just to know stronger that -1 means 'error in errno'. man 2 mkdir -> yup. 1620 ok. so the internet said the problem was statx, and i'm getting a failure in mkdir, maybe this means the call to mkdir was done in result of a call to statx or something dunno. i'll look in the source to see where mkdir is called. the line with mkdir appears to be 2182. i'll output errno 1622 and errno has unknown type, plz cast it (int)errno is 17, i'll look that up in /usr/include oh hey i had a brainflash and typed 'perror 17' on the command line: file exists. ok so mkdir doesn't expect to be passed an existing path. let's check the caller's behavior. it's 1624 and create_directory is called at the end of create_directories plural on line 2136. okay, it calls detail::status which is returning wrongly that the directory does not exist. 1626 made a progress ! woopty-woo!
it's 1823p and i set a breakpoint on the call that's reporting the dir to not exist it appears to be correctly calling stat, not statx the path is /home/user/.bitcoin . it' s a sylink to a folder on this raid. 1825 the stat function is defined in /usr/include/sys/stat.h . it's an inline that was pleasantly not inlined. it calls out to __xstat and is being passed the right folder. 1826 stat returns 0, success. the structure thgat is output has modes and uids and inodes and sizes and all that. 1826 1827 ten it gets the mode on line 3253. it's 16877 . i am not witnessing the function return "directory" instead of "not found". guess this breakpoint is not on the issue. 1827 guess i'd better keep continuing until the problem is hit. 1828 okay. it says the subfolder .bitcoin/blocks is not found. is this true? yes. this folder is missing. 1829 errno is 2 now: no such file or directory i tried typing mkdir /home/user/.bitcoin/blocks on the command line, and it fails with 'file exists'. 1831 1832 okay when i typed ls to look for the 'blocks' folder, i was looking at output for the wrong directory. this issue has a resolution: my blocks folder is a broken symlink. whew. 1834 bitcoin is running for the first time in quite some time. my block database is empty on this system, unsure why. i can rebuild things in release mode.
1850 it was such a small issue in the end. [inhibited: i didn't think i'd be able to do it.] the next step is to see if i can sync the whole chain, which is rare for me. they've really made the syncing phase lighter weight, i think, nowadays, unsure. i'd also like to get the bitcoin-sv chain. not sure how big it is. 1851 my raid claims it has 276G free. not that much. 3.3T are used. 1852 i'm looking for information on the bitcoin blockchain size using google. my network might be saturated by downloading the blockheaders; the result i clicked is not loading. 1853 the loaded-without-images result said the blockchain was about 360G large. so i'm either going to be deleting files or pruning it. i really want to scrub the whole chain for content, but i'm more likely to lose it to corruption or something before i do that, so pruning makes sense. it also sounds like i should be using a further harddrive, and i still have an enclosure indoors. 1855 i'm using zstd to compress some files to save space. from the cornucopia of facebook, inc. 1858 is there some magical thing that gives you infinite diskspace? there's some new tool that i vaguely recall might do something like this. it might not work for a blockchain. 1901 rclone! rclone can mount with fuse and has a variety of storage backends. i dunno if it would work, maybe it would at least work for archiving other stuff. 1904 anyway my blockchain is now updating tips so i have the space issue developing. i guess i'll stop it and configure it to prune. 1908 i had actually deleted the binary to rebuild in release mode, so stopping the node prevents restart until the rebuild finishes. oops. 1920 blockchain is syncing with -prune=$((1024*16)) i.e. 16 gigabytes of blocks are kept. and i have 3 huge files compressing with zstd, using --ultra --long -22 so it is very slow. with this compression i may have space for bitcoin-sv. i also have a blockchain folder named bitcoin-sv. it's only 2.5G large ... but uses another symlink .. which is also broken. i guess i'll try to build bitcoinsv too, maybe it has a pruned mode. 1922 1929 bitcoin sv build has started. bitcoin is at 2010-11-30. maybe there's some way to checkpoint for last-mile folks, dunno, haven't looked into it. system's pretty taxed now. 1930 a hard thing that's remaining is software to archive files on bitcoinsv. as mentioned long ago i've slightly worked on some messy software for this. it relied on apis that have since changed, so development work is needed. the current state is messy and i don't recall my plans for it. great topic for these spamlogs, since it's very hard to move forward on. might be time for another task tonight, like sleeping, unsure. 1931
On 11/5/21, Karl <gmkarl@gmail.com> wrote:
1858 is there some magical thing that gives you infinite diskspace? there's some new tool that i vaguely recall might do something like
Use the latest ZFS, turn zstd compression on poolwide, rewrite the datasets. It's the closest to magical.
it might not work for a blockchain.
At least 9% less fully indexed, 50G freed. If you want to save more space, you have to hack the different BTC forks to refer back to the BTC chain for the parts in common prior to the forks. Buying disk is easier.
system's pretty taxed now.
Use dbcache, dbbatchsize, etc.
1930 a hard thing that's remaining is software to archive files on bitcoinsv.
You should be able to scan through all tx writing each attachment into a filename <txid>-<content_hash>
Thank you so much for these kind ideas.
If you want to save more space, you have to hack the different BTC forks to refer back to the BTC chain for the parts in common prior to the forks. Buying disk is easier.
hadn't thought of the source mutation (nor did I know zfs had zstd). you can use hardlinks to deduplicate the block files, too. takes some carefulness. note to self: disks with dedicated purposes might be simpler for me
1930 a hard thing that's remaining is software to archive files on
bitcoinsv.
You should be able to scan through all tx writing each attachment into a filename <txid>-<content_hash>
0637 edt this error is from bitcoinsv: bitcoind: /home/user/src/bitcoin-sv/src/validation.cpp:2889: bool BlockConnector::Connect(cons t task::CCancellationToken&): Assertion `hashPrevBlock == view.GetBestBlock()' failed. Aborted (core dumped) i think it is innocuous and just looks scary, unsure. reindexing and wiping chainstate pushed it away. grarpamp recommended an incredible idea of indexing the files on a blockchain. doing this would work best if i had a synced chain. bitcoin is presently on 2015-05 so is still just barely started syncing. maybe i can find a downloadable chain somewhere. 0638 0639 and i found https://bitcoin.stackexchange.com/questions/799/can-i-download-the-whole-blo... it contains this sentence: " Network and synchronization code have been immensely improved over the years so that the initial block download via the network is usually acceptably fast." This is not my experience at all. maybe the db flags grarpamp mentioned are my issue? i don't know. i likely also have some blocks on harddrives indoors. indoors is dangerous for me because it is hard to leave. 0640 it's 0642 and my internet does not appear to be working. i'll inspect the antenna. the phone i'm using as a flashlight is at 8% after being plugged in when i got here. 0645 and net is back. it's 0647 and now i'm at https://bitcointalk.org/index.php?topic=145386.0 it's 0650 and i'm using google to search for "how to sync blockchain fast". 0655 and i'm trying to figure dbcache out. it's in the bitcoind --help. dbbatchsize i don't see there yet. i bumped mine from 450M to 3*1024. hasn't allocated that much ram yet. 0657 given this will take longer to complete than i can remember what i am doing, options include: - getting blockchains from indoors - using another client, such as a light client - doing something else i've been thinking a little about libbtc. it's at https://github.com/libbtc/libbtc and i think i may unfortunately be a maintainer of it. it was a light client. it doesn't have the bloom protocol stuff implemented yet, but it can probably be used to scan peers for blocks pretty reasonably, maybe even validate them using some old protocol, who knows. there's also libbitcoin. the problem with libbitcoin is that it is huge. binaries take up a lot of disk space. it also has a large build infrastructure. wouldn't normally be a problem if you weren't me, i imagine. i have an existing project for indexing chains. i actually have a lot of them. but one of them is recent. it's hard for me to access and think about these projects, and i tend to make them a mess before dropping them. it's 0700. let's see if i can find it. additionally, it's best to have the whole chain, and that's hard for me with the current amount of space i have. my concern with buying more disks is that i tend to fill them up in ways that are hard to manage. they also develop corruption, and then i preserve them in the hope i can recover my files at some point. the files are generally unreasonable to recover for me, but that's very unfamiliar to me, which confuses things further. learning zfs seems like less of an investment than working on a chain project. i've tried them both before, failed at them both before, but chains keep growing whereas zfs isn't really that flexible. it does provide rollbacks which would really help with my corruption issues. chains do too, but are less normal to use for storage. filecoin btw is kind of a joke. they rewrote the protocol so that interactions with hosters are done out of band, and the protocol doesn't enforce maximizing the storage economy the way a proof of work does. so basically you can't use the blockchain to escape file censorship because the storage protocol is out of band and you're responsible for doing your own duplication of content by finding multiple hosts. it didn't work for me. hosters rejected my content or didn't respond to my pings. the previous whitepaper looked great. but we have lots of other chains and lots of ways to get people to respond to pings, if one focuses on problems. filecoin takes a modern system to run (uses gpus), is another barrier. it's 0705. what is my last chain interface project. confused. another approach would be to contribute stuff to bitcoin so it can be used as a light client. that's probably sorely needed. my phone alarm is going off loudly. it's 0706 and my body is trying to leave this system. inner conflicts exist. it's 0706 and two blockchains are syncing pruned. my system has 3G of ram cached by the os, thinking my dbcache value could have been larger, dunno. 0708 i'll look through my github repos to see if i can find anything like a blockchain database interface it's 0709 and my internet is down. the device has disappeared from network manager. when i type nmtui-connect, the system hangs. this is happens to me sometimes. this email is likely to be lost, so i'll copy-paste it into a dated file, and keep writing in the file. it's 0710 and i'm writing in a file instead of a web browser. my system is experiencing a kernel issue associated with my wifi device. blockchains think they are syncing, but have no network to do so with. some zstd processes are still running, compressing things. it's 0711 and i'm switching into terminal mode i'll use a different tty to try to become root. this can take a long time as the kernel waits for network time out, doing some host lookup in sudo. [maybe, guessing.] first i get to log in. it's 0711. i've entered my username in a tty login, and am waiting for the password prompt to load. this is how my system behaves when my wifi device glitches out. it's 0712 and the password prompt loaded. i've logged in, and am waiting for sudo to respond. it's 0713. this is a redhat system, a gifted subscription from a family member. it's running redhat 7. i've opened a support ticket around the wifi issue before, but i ended up having cognitive issues before resolving it. one of the upshots of that various exploration, is that now crashdumps are enabled in my kernel. there's some way to issue some sysrq to make one. it makes sense to do this in this system state. sudo is still waiting. it's 0714 and i'm looking for information on triggering crashdumps on my phone. it's 0715 and sudo is still pending, stalled after typing the command in. i've loaded 'How to troubleshoot kernel crashes', a redhat article, on my phone. after spending some time with redhat, i've also started pursuing ubuntu, which seems to have a more widely used package management system. generally, if you have paid support, you have an issue: you need to be able to contact the people offering you paid support. this is most reliable if you can physically visit them. haven't looked into that. the article says you can write 'c' to /proc/sysrq-trigger. maybe you cam hit c as a key too, dunno. it's 07:19. sudo still pending. it'd better stop my zstd processes so that i don't get confused by having zst files with half content if the system reboots. stopped, partial zst files deleted. some of thse have been running all night. i must not know how to do it. when i hit alt-sysrq, some kernel stuff scrolled by, then hitting c did nothing. here's the kernel stuff: [147513.443091] CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: P OE ------------ 3.10.0-1160.45.1.el7.x86_64 #1 [147513.443219] Hardware name: LENOVO 20K70004US/20K70004US, BIOS N1QET79W (1.54 ) 11/16/2018 [147513.443303] task: ffff89ec367a5280 ti: ffff89ec36204000 task.ti: ffff89ec36204000 [147513.443379] RIP: 0010:[<ffffffff9fbc8dc7>] [<ffffffff9fbc8dc7>] cpuidle_enter_state+0x57/0xd0 [147513.443483] RSP: 0018:ffff89ec36207e60 EFLAGS: 00000206 [147513.443540] RAX: 00008629e94d4d1d RBX: 00000000000159a0 RCX: 0000000000000018 [147513.443648] RDX: 0000000225c17d03 RSI: ffff89ec36207fd8 RDI: 00008629e94d4d1d [147513.443817] RBP: ffff89ec36207e88 R08: 0000000000000ae5 R09: 0000000000000018 [147513.452141] R10: 00000000000031dc R11: 7fffffffffffffff R12: 0000000000000001 [147513.459738] R13: ffffffff9f6c9f6d R14: ffff89ec36207e28 R15: 0000000000000087 [147513.466787] FS: 0000000000000000(0000) GS:ffff89ef62500000(0000) knlGS:0000000000000000 [147513.473205] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [147513.479148] CR2: 00001d110871a000 CR3: 00000001ae210000 CR4: 00000000003607e0 [147513.484452] Call Trace: [147513.488474] [<ffffffff9fbc8f1e>] cpuidle_idle_call+0xde/0x230 [147513.491680] [<ffffffff9f637c8e>] arch_cpu_idle+0xe/0xc0 [147513.494654] [<ffffffff9f70181a>] cpu_startup_entry+0x14a/0x1e0 [147513.497325] [<ffffffff9f65a827>] start_secondary+0x1f7/0x270 [147513.499793] [<ffffffff9f6000d5>] start_cpu+0x5/0x14 [147513.502018] Code: 40 ee b3 ff 4c 89 e6 48 89 df 44 89 f2 49 89 c5 49 8b 47 48 e8 9b f1 dc ff 41 89 c4 e8 23 ee b3 ff 48 89 c7 fb 66 0f 1f 44 00 00 <4c> 29 ef e8 b1 a5 ad ff 48 69 c0 40 42 0f 00 b9 ff ff ff 7f 48 guess i'll wait on sudo and look in the article or on the web for more information on triggering a crashdump via keystroke. it's 0723. 0725 the internet sounds like i had it right: hold alt, hit sysrq, hit the command key. i'll try again. it's 0726 and i realized my system has no sysrq key. i must have hit some other key, such as scrlk, thinking it was sysrq. my goodness. i'll check the proc file and see if it's world writable. it's 0726 and /proc/sysrq-trigger is writable only by root. sudo is still pending. my toes and fingers have been feeling more cold since my network went down, possibly due to personal stress since the sun is rising and it should be getting warmer. i'll spend some time warming them. while starting to warm my toes and casually glancing at the page open on my phone i saw that prtsc may function as sysrq. i'll try that. it's 0730 it's 0736. i took a crashdump; it appeared to work. after it took the dump it said it was rebooting, and the screen went blank with a nonblinking cursor in the upper left. i used the soft power button to hard reboot it. when it came back up, there was no bios, and the screen with the cursor was still there. i did the same thing again with disconnecting all the peripherals, and this time it worked. i plugged them back in as it was booting, and the kernel hung before accepting a decryption passphrase, saying there was an over current condition on a usb port. my usb ports are old and buggy. i removed the wifi adapter, since it was the focus of the issues earlier, and rebooted, and got to the decryption passphrase. i plugged it back in and the system booted normally. i am online again. it's 0738 and i'm attached to a restored tmux session. it's 0738 and i'm back in tmux. here's this: $ ls -l /var/crash/127.0.0.1-2021-11-06-07\:32\:01/ total 318244 -rw-------. 1 root root 325454858 Nov 6 07:32 vmcore -rw-r--r--. 1 root root 410893 Nov 6 07:32 vmcore-dmesg.txt $ sudo sha256sum /var/crash/127.0.0.1-2021-11-06-07\:32\:01/* [ed, meant to remove this:]sha256sum: '/var/crash/127.0.0.1-2021-11-06-07:32:01/vmcore': Permission denied d7133f7f0056961de878f4465c22767cb14f2906d2730be758074526f5ceaa87 /var/crash/127.0.0.1-2021-11-06-07:32:01/vmcore 8187db7cd0e16dec349cd6b552210294861bc003759031a0b30d05ad974a12b3 /var/crash/127.0.0.1-2021-11-06-07:32:01/vmcore-dmesg.txt i'll boot the gui back up and get this document back into an email so things make more sense. that'll also help send the vmcore to redhat or whatnot. it's 0740 it's 0742 and i'm working on warming my extremities. not in email yet. when i got paranoid and delusional i got chilblains for the first time. i was scared and didn't spend enough time rewarming my feet when outdoors, because i was scared. i remember repeating to myself when that happened -- or maybe i don't, all of a sudden, who knows. anyway: the thing i used to do, was when my feet were cold (like getting numb), i would stop whatever i was doing, and just spend time warming them -- until they were completely warm and comfortable. doing that for a couple years, i ended up with my feet staying warm on their own. so it was a decreasing curve, roughly. i don't remember how i used to warm my feet, though. but little bits come back to me here and there. i think part of it might have been taking off my socks and holding my bare feet; i think that might have been part of it. maybe i'll try that on one foot now. i can put the socks from that foot, onto the other one. it's 0754 and my inhibitions are engaging my foot warming behavior, making it severely harder to sustain and develop. i guess i'll kind of take it adhoc. things are funny and i have a mitten on my foot. it's 0755. my feet feel okayish, temporarily. 0758. back in an email. i'll send the email, and also plan to reboot the bitcoin clients and zstd processes if reasonable. my tmux session wasn't updated because i took a crashdump before closing tmux.
0801 i have not rebooted anything nor sent the vmcore to redhat my harddrives aren't showing in the system. the usb hub they are connected to has no usb ports lit (usually has blue lights when ports active). when i unplug its power cable, the blue lights briefly light and then turn off. they do not turn on when the power cable is plugged in. it's 0802 and i'm considering troubleshooting a usb hub, but instead pausing. it's 0812. the go-indoors demand is acting up again, after thinking about sending the last e-mail. i might go out to my sleeping bag, without getting my disks running again, to try to stay outdoors. one of the ways i stay outdoors is by bringing candy outdoors, and never eating it indoors. so, outdoors is always a place to find candy. or other things similar to that. i have something in a box i could try, to appease the go-indoors urge. it's 0813. it's 0816 and i've found a state of mind where i can have muscle spasms and laugh while holding my feet in an attempt to warm them. i have only one layer of damp wool socks on them, so they're not likely to get all the way warm, but since i am holding them they are unlikely to get colder. it's 0824. the active-memory-amnesia i'm having around warming my feet is similar to that i have when trying to design software. i'll send this e-mail since i'm not making progress on the goal.
it's 0839 i've got the disks back up i'm getting the std::bad_alloc error again when i launch bitcoind unfortunately, i rebuilt everything in release mode. back to debugging symbols. it's 0840. part of me wants to eat food. i'll set some stuff building first. 0846 so here's the chunk that is causing the memory error, in boost::filesystem 1.76 path.cpp: 195 BOOST_FILESYSTEM_DECL path::string_type::size_type path::append_separator_if_needed() 196 { 197 if (!m_pathname.empty() && 198 #ifdef BOOST_WINDOWS_API 199 *(m_pathname.end() - 1) != colon && 200 #endif 201 !detail::is_directory_separator(*(m_pathname.end() - 1))) 202 { 203 string_type::size_type tmp(m_pathname.size()); 204 m_pathname += preferred_separator; m_pathname is empty, so then the && condition dereferences 1 minus its end pointer, which looks like an error,could be wrong. its type is boost::filesystem::path::string_type, which must inherit from or be a typedef to std::basic_string, since that's where the crash happens. it happens in the call to string::end, strangely. it's 0850. whelp, i made some great strides, inhibitions might be dominating now. doing things by spamming descriptions of them is a little delicate i guess. 0851.
0523 I put a breakpoint on line 197, and m_pathname.size() is 140737488342416, so likely a memory error, maybe caused by some mismatch library version. 0526 valgrind --vgdb-error=1 reports that uninitialised memory is accessed on that same line 0529 idea: maybe boost headers differ from libs. 0531 setting LD_LIBRARY path resolved the crash. 0536 2021-11-07T10:36:02Z Error: Error initializing wallet database environment "/home/user/.bitcoin"! This error could occur if this wallet was not shutdown cleanly and was last loaded using a build with a newer version of Berkeley DB. If so, please use the software that last loaded this wallet could be related to me kill -9'ing the valgrind process 0537 gdb, catch throw -- did not catch the error, so i'll grep the source or its text or view the log 2021-11-07T10:37:28Z BerkeleyEnvironment::Open: LogDir=/home/user/.bitcoin/database ErrorFile=/home/user/.bitcoin/db.log 2021-11-07T10:37:28Z BerkeleyEnvironment::Open: Error -30974 opening database environment: DB_RUNRECOVERY: Fatal error, run database recovery that sounds pretty simple! i just have to run database recovery, whatever that is. 0538 . logfile is full of this: Unacceptable log file /home/user/.bitcoin/database/log.0000000002: unsupported log version 19 Invalid log file: log.0000000002: Invalid argument PANIC: Invalid argument process-private: unable to find environment 0542 i backed up my .bitcoin/database folder and it's running 0547 i'm spending some time trying to normalise my boost setup so it won't make crashes from misloading itself 0548 some dialog: i experience weird network separations. for example, i have experienced these things: - broadcasting a transaction locally, having peers hold it in their mempool, and not have it show up on exchange UIs - broadcast a transaction on exchange UIs, and not have it show up locally - running an onion service locally, connect to it on the same system via tor, but get connection refused over tor from my cell phone - getting dns resolution failures on some systems for some websites, that resolve fine on other systems so basically i have paranoia around huge network attacks. i'd like to know my use of the blockchain is functional even if my internet is entirely fake. but what's most important is being able to do things at all. it can be hard to keep that clear in my emotions. 0552 i reinstalled boost, i'll rebuild bitcoin using system libs 0602 i looked a little for my blockchain indexing project. i found libgame, which was a previous version of it. i think i had forgotten about libgame when i made it. libgame was going to be like a video stream sharing app with other functionalities too. the indexing project would fit in well. 0604 ok here it is: libonchain. 0605 i'd like to move straight towards indexing files or blocks or something in a way the user can see. so maybe find a spot in one of these projects where that could fit. 0609 things seem stalled. moving again after handling some motor issues. 0611 libonchain is updating submodules but appears stalled. i checked the process writing to disk and its file position isn't moving. wonder if there's a verbose mode. 0612 --progress 0616 running into this in my own code: fatal: No url found for submodule path 'deps/libbtc/src/trezor-crypto/tests/wycheproof' in .gitmodules i'm guessing there's a submodule inside a subtree dependency, and this is make the universe look like a giraffe wearing a vr helmet at a submarine party doing undersea research. possibly normal when i'm involved in something. 0617 0621 i ended up looking into the error a little which i guess should just be adding a line to .gitmodules or somesuch. i discovered my strategy for taking on partial maintenance of libbtc partly involved an attempt to reference the work of other projects directly to make things easier to maintain. interesting idea. if libbtc isn't a normative library, it could reuse work from some other library that is. it makes most sense to reference bitcoin core directly. then protocol change updates are pulled in. i think i recall settling on that plan with libonchain, not sure. 0622 0631 i'm glancing through my cmake file for libonchain and i think the issue i ran into once is that the state of the main bitcoin tree is partial for library dependencies. some of the functionality has been pulled out into a library, but this set of functionality is roughly random. it looks like the goal of modularising it fell to the wayside, dominated instead by a goal of making working changes to the main client. i'm thinking it might be simplest to handle that by making my own library that references sourcefiles in the subtree. could be wrong. since i'm not much here. what i'd basically like to do is connect to the peer network and retrieve blocks without actually syncing. so, most of the bitcoind binary, but maybe with a different main function. 0633 the tags in bitcoin are a little strange ... seem to jump from v0.19.2 to v22.0 ? maybe they decided to drop the '0' and skipped a few versions ...? 0639 libbtc pull requests require test passing to merge, and the ci service is no longer running jobs. yeesh. for later. 0640 found the tags my eyes had missed 0643 things i was rebuilding are encountering build errors. 0648 build is using std::__cxx11, libraries don't . make VERBOSE=1 shows -D_GLIBCXX_USE_CXX11_ABI=0 0650. must have made an error. build appears to not use __cxx11, whereas libraries do. 0702 ok i jumped through some git hooks. when i try to build the current libonchain code, which includes libbtc as a submodule dependency, it fails due to an incorrect preprocessor symbol in wallet.h i thought when i looked at the source in the main libbtc tree, that wallet.h was correct, and i thought i just updated to the main source. my psychosis makes it hard to check things that don't line up, as then i can notice when it is teaching me to be delusional. 1. check main tree again. libbtc/master correctly has LIBBTC_BEGIN_DECL . 07933995eb5010a016c75fb703a66023116013a3 2. check the tree that is failing build. libbtc/master is _also_ correct in the submodule tree. i'm guessing cmake copies the sources and didn't update. i must have struggled with that for some time in the past, so i'll just wipe it and see if that helps 0712 onchain built. libbtc provides an existing interface to a simple bitcoin p2p network thingy. it gets inv and header messages. it's probably reasonable to also ask for blocks somehow. this could be a path to just enumerate blocks available on the peer network, and index their content. the existing code is likely not organised very well. but it's likely workable in some manner. 0713 not sure whether i will continue this at this time. i would like to make a fuse interface to the blockchain, because i haven't been able to use fuse since my problems began around 2014 when i made a fuse interface to another computer's live ram.
On Sun, Nov 7, 2021, 12:31 PM Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:
On Sun, 7 Nov 2021 07:14:14 -0500 Karl <gmkarl@gmail.com> wrote:
0523
are you the fucking idiot who called me a spammer karl?
I call _me_ a spammer, I am an idiot, I don't fuck much, I called you a _producer of spam_, I don't believe you are a _spammer_ yourself. I think possibly you have been forced to look like one. I can't know.
participants (3)
-
grarpamp -
Karl -
Punk-BatSoup-Stasi 2.0