hello personal journal oh you're not a personal journal you're a mailing list of elite researchers and techs that has been consistently harassed by strange influences for decades? um. hmm. okay, I was going to journal about some issues I have engage tech contributions, that are struggling due to strange influence, but now I feel bad that I may be harassing the members of this list in doing so. this is the purpose of my [spam] tags. is it maybe ok given the [spam] tag? maybe a little? no? you say that some kind of government and corporate surveillance networks can still somehow use my post to harm the people here? or you're worried that some people might read my post, even though it is tagged [spam]? ummmm well, I don't want to worry you this way. i'm really handling a lot of ashamedness here. ummmmmmmmm ummm there must be some way we can sort this out. some way I can contribute to the list rather than harming it? I mean honestly spamming this list is _so_ helpful to me. really very helpful. a boss? a government agency? no, I don't work for anyone. you don't believe me? you wonder how spamming the list is helpful to me if i'm not being paid to do so. ummmm it's hard to talk about that. you knew I would say that? well, maybe i'm not very good at communicating. i've always been a pretty poor communicator. this is really _very_ hard to explain, um .... honestly I was brainwashed by -- wait, don't go! where are you going? omigod are you okay? come back? is that blood? oh! you're spamming the list too! do you think by spamming this list we can somehow get code written? you can't seem to answer that? are you sure you're okay? it's very hard to be forced to spam a list when you think you're working on software. let me show you one of my strategies and maybe you can improve on it. I mark the time as I try to work on software. it's 12:52p EDT on 11/4/2021 and there's been a major development in a pull request I have open in libusb. unfortunately, my cognitive issues have been getting in the way of responsibly addressing it.
1259 The pull request is #874 at https://github.com/libusb/libusb/pull/874 . I wrote a basic android backend for libusb in like a forced clarity burst for another project. libusb is starved for maintainers, and by the time anybody got to it I was in a different state of mind. long story short, it is now _very_ hard for me to engage, has missing functionality and disorganization but is still a huge improvement on the in-tree android situation, and works just barely well enough for a lot of people to use. a few months back, while my pr was still in review, a developer committed some changes to the main tree that broke all nonrooted android functionality, even the old stuff still in the main tree. the changes engaged the same option handling code I extended to add android java interaction. 1303p second long story short, a new maintainer from debian finally merged in an adhoc fix for the breaking changes. my pr was on pause, because I didn't know what the final fix would end up looking like. it ended up looking like whatever the last proposal happened to be, because nobody was around to comment on design choices, which is an interesting thing to add to one's experiences. 1305p
1306 so, my responsibility appears to be to mutate my pull request so it at least merges properly with the current state of the tree. ideally i'd like to improve the design in how I add the functionality I am _very_ confused around it, which I state to help process the inner sensation. 1307 I have it open on a computer which currently has its display asleep. i'm outside still, in the back of my box truck atm. I haven't brought a computer out to where I sleep in the woods right now. the temperatures get down below freezing sometimes but no snow yet. electronic devices have different patterns of behavior at very low temperatures and with changing humidity. some break permanently. some function impeccably. kinda funny. 1309 I am really scared of this work. it's been pending a couple days now. we've all seen me go through my silly struggles to do tiny software stuff. I still haven't gotten bitcoin running. 1309 my current issue is that, after reboot, shell commands are segfaulting inside my restored tmux session. outside the tmux session, they don't segfault, they work fine. this experience is somewhat conflummoxing for me. when it think of why it might happen, the brainwashed bit of my mind sees me considering hacking or a virus, or even a systems level bug, and freaks out to stop me from discovering any possible govcorp espionage which I did once very very long ago now. I don't know why my shell commands are segfaulting inside tmux. I'll look at it again. 1312 $ ls -l Segmentation fault (core dumped) $ echo hi hi oh I think I thought of it! I did something that can be very unwise: I built and installed a new glibc version. maybe I installed it somewhere that's pulling it in. but it thought I gave it a local path I wonder if gdb works $ gdb Segmentation fault (core dumped) 1314p ok hmmmmmmmmmmmmmmmmmmmm $ ldd Segmentation fault (core dumped) let's say it is indeed dynamically loading a library that it shouldn't. if it's because the tmux environment is different from the surrounding environment, that would be visible in environment differences ah-ha! LD_LIBRARY_PATH includes the cwd, and i'm in the glibc build folder. whoo man. 1315p yayy leaving the folder makes everything work. omigod. that problem seemed so incredibly insurmountable.
1320 arright let's check out this libusb thing i've seemed unable to address for 2 days. one of the issues is that there are a lot of paths forweard and I keep switching between them, always deciding a different one is better, never making progress. 1321 one solution to having many approaches is to make a different worktree for every approach. `git worktree` lets you make different worktrees inside the same git repository. another solution is to pick one for a nonrelated reason such as being the first one, and stick to it hard. i'll probably try the worktree one here, unfortunately. 1323 I have some existing code open that is an offhand rebase of my code onto the new main tree. it has 2-3 prominant bugs, one of them kind of confusing. what it comes down to, is that i'm not sure how to initialize the javavm pointer in the new setup, and here writing seems like it could be pretty helpful. the android javavm pointer is passed in by the user right now, as a libusb option. 1323 and i'm having chest contractions the issue is: the pre-init options are now passed to the backend twice. once when the user sets them. and now a second time before the backend is initialised. this lets the library manage defaults in some way. i'm going to review the code that passes them on the first time. after writing it to this list, the first time seems kind of unnecessary. 1328 I have a "master" worktree already. oops. I jostled my phone cable because the phone wasn't charging. it is now charging but my usb hub developed an issue and my raid array disconnected. looks like only one disk possibly went down 1329 1330 mdadm is misbehaving, but my libusb code is not on the raid array, so i'll ignore the issue for now 1332 I found the libusb call I want to inspect. my arms try to move away from the system, so I dissociate and find a way to at least get them near, then dissociate again to do the task with them. it looks to me like this redundant call could be removed to retain the same functionality. if i'm going to try that out, I'd likely want to test the changes. the guy who did the fix contributed a test app in a different repository. 1334
1345 k I visited the pr page and a visitor actually figured out how to make the branch work which is a huge relief i'm going to keep poking at this anyway. my intent when visiting was to find that test app. still haven't found it. also the visitor mentioned something i'm not aware of that I forgot to ask about. oops. 1346 1356 still trying to find my way to that test app. at least i'm here in this email composition window again. not too lost. 1357 1400 I didn't find the link to the repository but ended up finding it in the user's repository list, at https://github.com/harbulot/LibUsbAndroidIssue942 . let's clone it! 1401 okay um - internet not up on system to clone - I already have a different test app cloned here it seems i'll get this test app too I guess. 1402 yay internet came up without issue it's downloading the gradle version the dev used
1408 oookay my android sdk was on the raid array. time for a quick reboot to simplify things I often don't reboot my system due to my difficult hitting the "save" command on my notes. but recently it was rebooted, so no notes. 1409 my initrd for like a year now does something weird where it doesn't prompt for my encryption passphrase on boot, until I hit "enter" first. I haven't looked into why this is. 1410 tmux is restoring my panes. all the content is lost, I hear you can fix that, but I like to pretend that at least organising them in the same layout preserves the notes a little tiny bit. 1411 1412 yay gradle is downloading dependency aars. They were changed from apks to aars some time ago, piratey. here we go. ummmmmm I guess i'll run it, then make a change and verify I know how to rebuild, then try to remember why i'm doing this. 1413 1414 install is hanging, but adb is working, I rerun install oooh adb stops working. grumph. I have a solution to this: I toggle adb debugging in android settings. 1416 installed successfully. run time. 1420 test app failed. onward. i'm rebooting the system again to simplify hacking knocked the raid array again, looking for a test usb device. note: I have an enclosure to secure the array better with, indoors. the system is hanging shutting down, likely due to the raid array having been knocked and disconnected during use
the guy on github isn't familiar with github or something, and it's quite confusing. 1429 pretty hard to continue. maybe with some time I can understand how to respond to the guy. i'll move forward and testing the stable code with the test app. then i'll try adding my change. if I ever finish, i'll plan to tell the guy, "hey what you said was kinda confusing to me, so I just did it". 1430 tmux reloading panes again 1431 1432 gotta bring raid array up. looks like my usb hub is unpowered. 1434 gotta reboot android 1435 k test time 1436 test passed. which gives me working code and shows me how to rebuild this project at the same time. i'll try removing the extra set option call, and look at appropriate control flow logic hopefully. okay. I remember now. wait. no. I don't. 1438 1439 the first confusing thing is the check in libusb_init . it passes the default options to the backend again only if no ctx pointer was bpassed, and there is no default ctx pointer. ok, so it only passes them, if it is making a new default ctx ptr. meanwhile, the old android flag had set a static flag and ignored the ctx pointer. my new code associates the flag with the ctx instead. currently unstable. the current code still ignores the ctx pointer. 1442 so, the current tip code assumes that options are associated with ctxs. if no ctx is passed, it stores them as defaults: but it only passes them on if creating a default ctx. so there's maybe a tiny leakish, for this use, in hjelmn's code where defaults set with no context, are unused if the user sets a context and something else with harbulot's code with the old android code, defaults were set for the context before it was created. this could mean passing them on, even if the context is not the default. alternatively, the intent of hjelmn's code could have been to set options on context storage before it is initialised. I guess that seems a little unsafeish to me, unsure, nobody's mentioned trying it I guess. 1445 so what's the plan seems most direct to pass defaults in whether a new default context is made or not alternatively we could stay near the current code, and set defaults when the option is passed, and read straight from the defaults. I thought of two approaches to the option situation I might as well add as comments to a different issue - options could be passed on an uninitialised context - the backend could be refactored to initialise on use, so that early options can be passed after it is constructed regarding the first option, it seems that the user only has control of context pointer storage, so that's not too workable unless allocation is separated from initialisation k I submitted those ideas to their issue for such ideas 1454 ok um copypaste: seems most direct to pass defaults in whether a new default context is made or not alternatively we could stay near the current code, and set defaults when the option is passed, and read straight from the defaults. it seems more compatible a little to keep the approach I currently have of setting the defaults in the option handler, and reading from them to manage the options. this is similar to the solution bits made by the visiting contributer. 1455 current issues include: - deadlock, roughly resolved - segfault? let's see what he addressed right. my option handler checks wrt null. this issue should go away if duplicate passing goes away. but basically, it's ok to reset it if the value is unchanged ... I guess ... maybe ...? i'll try looking at it! I think I might be able to complete this! 1459
1501 k my interpretation of the condition for forwarding the defaults to the backend a second time in libusb_init was incorrect in f7084 by harbulot, the condition is changed from (!ctx) to (ctx || !usbi_default_context) this results in forwarding the values when there is a ctx, which wasn't previously the case. there might be a logic error here regarding default ctxs? i'll increase git's diff output 1513 1517 ok in libusb_init, ctx is the pointer-to-a-pointer passed in. nowadays if it is null, a default context is supposedly used. meanwhile _ctx with its preceding underscore, is a zero initialised block of memory that will be the new ctx, allocated on the heap. it looks like this memory is allocated even if a default context might be reused. it looks like a logic bug may be present. it appears that usbi_default_context is uninitialised, so likely default_context_refcnt should be checked rather than it. 1521 default_context_refcnt is also uninitialised. it would make sense to fix these. I wonder if c supports static local variables. I guess I should maybe know that whether it's relevant or not. looks like they are. 1524. should be accessed with lock I imagine. I think there's some existing static locked stuff, unsure, can see what degree of protection against initialisation order they're using. I think they have a list of contexts maybe? unsure? oh great there's a default_context_lock and an active_contexts_list interestingly the check already compares the content of the structure with zero. I wonder if things are auto filled with zeros. it just contains two pointers, prev and next. maybe websearching can help me 1528 the internet does not yet appear to believe that happens. maybe they use some compile flag, i'll glance at them. they pass -std=gnu11 maybe i'll glance through c11 stuff and websearch more 1531 ok at journaldev.com I found "The default value of the initialization of the Static variable is zero (0)." maybe I can find something more authoritative ok I found a second source saying static and global variables are initialised to zero if not initialised explicitly. so I better reconsider this code, which looks much better now. 1534
1543 let's review this patch history again. with longer output context. and the knowledge that static memory is zero-initialised whether you want this or not. 1550 let's review this patch history again. 1553 so the default context reuse is right at the top of the function. if there is one, it bumps the refcount, points and returns, everything's good libusb_init locks around a global lock, so things in it are not simultaneous. the check if (ctx || !usbi_default_context) ... I think this is saying to only execute the block if a new context is being made? but isn't that always true? it replaced if (!ctx) which says, only if this is the default context. let's see if the block is always true. if ctx is nonzero, that's the normal case. then edge cases would be ctx is zero. if ctx is zero, then there's a block that checks for usbi_default_context being nonzero, and short-circuits, returning. so, after that block, usbi_default_context is zero if ctx is zero. therefore, ctx || !usbi_default_context .... uhh is saying ctx || (!ctx && !usbi_default_context) and we just said that those two being zero, one implies the other so ctx || !ctx, it would always be true. hard to verify. 4 cases, 4 combinations of nonzeroness. 1 is eliminated by the short-circuit: !ctx, +dflt leaves 3: ctx, dflt; ctx, !dflt; !ctx, !dflt 1601 1603 boolean logic! woot! oh man my whole universe is partial truth tables right now omigod trues and falses, everywhere I just so badly want to question whether true is _really_ true, or false _really_ false. could a 1 or a 0 be a trick? you never know! !ctx, dflt <- eliminated by short circuit? remaining? -> ctx, dflt; ctx, !dflt; !ctx, !dflt 1606 suddenly taking a break
it's 1615 edt and I'm still here. my body feels pushed away from the work, an imaginary experience I often have. the word "imaginary" means that the physical things that are happening are firings of neurons in you. palsy can be "imaginary" if you have an abusive family member. what I mean is that my experiences are so bad I have actual muscle contractions. still, the danger stimulating their sudden behavior is on a very neurological scale. it's 1617 ! wake this computer up. bing. k we were handling logical conditions !ctx, dflt : short-circuited. see first if block in libusb_init, is exact map. remaining: !ctx, !dflt ctx, dflt ctx, !dflt now we can go down to harbulot's block. the first half of the or covers ctx, so that's 2/3 the second half covers !dflt, so it's an always-true condition. 1622 k so now every default option is passed to the context, it may be fine to remove the initial callback, unsure. the difference will be that there is no null pointer, but rather a context. so this change would go best with my addition that moves the flag into context-local data. the issue then is that these flags should only be set during initialisation. a way to check for that is whether or not the context has been added to the active list. I think i'll check briefly to see whether a list entry can be queried for what lists it is in. libusb has an internal list structure used everywhere. yes, actually! each list entry holds storage for its node in the linked list. so you can check without iterating and without additional data storage. personally I think it's cool how c programmers find ways to use like 12 bytes of memory max to do absolutely everything, as a norm. if everybody did this our devices wouldn't just be _responsive_ they would be _faster than we can perceive_ in like everything they do. but most people aren't c programmers. 1627 is speed dangerous ? 1628 ok so the plan is to ..... rebuild my changes to option setting, using context-local data, and checking to make sure the setter is called from libusb_init, by checking the list entry's state in the active list. it's zero-initalised with calloc so a non-zero check works.
1628
ok so the plan is to ..... rebuild my changes to option setting, using context-local data, and checking to make sure the setter is called from libusb_init, by checking the list entry's state in the active list.
it's zero-initalised with calloc so a non-zero check works.
it's 1643 and it might be lupper time all of a sudden. let's see. yes, I can stand up and find food, it may be lupper time. 1734 i'm back. multiple things happened. that was before 1743 now the universe is different. so the plan is to rebuild my changes to option setting using context-local data, and checking to make sure the setter is called from libusb_init by checking the list entry in the active list. the list entry is a context member. and. first. as I understand it it should work to remove the initial call to the backend, and rely on the init setter. let's see. an advantage to this is that the jni structure can optionally, or not, be constructed when the option is set. i'll try removing the initial call since the second call always happens. 1739 ok i'm looking at the first option call. issue 1 (later): usbdk is another option that uses this issue 2: this is the same call made from the constructor. oops. a quick fix would be to have the backend code do nothing. re issue 2: it's that the constructor actually calls this very function, so separating them would mean some change. ok. let's see. maybe i'll present my simplification as a pull request. maybe I can reply to the contributor too.
1754 i'm just gonna work straight on the goal, communication later. I get distracted like an explorer bee. ummmm the plan is to mostly keep the code the same. - we can pull out the second option setting call - we can change the no wait ... it needs to transform the option when set. ok so - pull out the second option setting call - change the condition in the handler to relate to the init list sounds reasonable. i'll change it in the commit it's made in, or make a further commit. ok let's see what commit i'm in right now. it's 1757. I think i'll make a new worktree and walk through my existing commits. it's 1759 and i'm about to bail! oh no! I already made the worktree! let's try not to bail when when all-day-attempt. 1759. made worktree. plan was to reset worktree to first commit. here go. 1800 1803 I picked up some food and spilled it around so my task now is cleaning the food up. i'm having trouble controlling my hands to clean the food taking it slower ok my right hand is working a lot better than my left so I can hold a light with my left hand and clean with my right. 1805. 1809 and the food is cleaned sufficiently. I was unaware I had such issues directing the fingers of my left hand independently, but now i've briefly experienced it. 1810 back to task. so, all the code for mutation is in my rebase. maybe I can open up the origin commits and change the check. additionally, i'll want to change the thingy with the other thingy. i'll look at it 1811. 1812 all the changes are in the squash rebase, i'll open it up ! 1818 ok I think I noticed an error in the main tree. on windows, when an option is set on the default context, it would dereference a null pointer it looks like it was introduced during the set_option kerfluffle i'll visit the github 1821 ok I was thinking of an old version of the code. when null is provided, the backend is _not_ presently called the first time. that is, it looks like presently, the backend is only called in non-null situations. the ctx pointer is always valid. mutating my code is the way forward. while github is open i'll submit the simplification. 1829 I totally replied to the comment on my pr! I am such a social butterinsect! butterinsecting everywhere I go ... ok i'm a little confused around how to handle all the stacked rebases. i'm kind of interested in going back to my original dev tree, and bringing it to consistency with the latest stable rebase. some inhibition. it's 1832 ! woohoo! 1832! I am spamming a list on the internet and it's 1832. near me is a laptop with github open. the temperature is dropping now the sun has set. i'll move the laptop to a dev terminal. dev terminal instead of github! yay! maybe i'll just fix up my last rebase and maybe add a commit to handle things maybe I won't keep a new rebase yet, but use the previous rebase 1834 1912 i've pushed two commits. just small obvious stuff. but i've decided to try to work off the rebase branch I already linked the other guy to. not sure what's next ummmmmm changing the check in options I think 1915 looking for the code, distracted again 1916 1958 so, there's a big issue, which is that my option takes a parameter, and the current code doesn't provide for that. i've spent what feels like the entire day today, after planning to work on this for a few days, resisting my psychological issues and trying to make progress on it, and i'm maybe a little bit farther than I was three days ago. I spent most of the day recovering confused ground.
participants (1)
-
Karl