>uncensored handholding >>>/d/ fucking disgusting i can't believe hdev is such a degenerate

Sauce, devbro?

>>11801 Dunno, sorry! It was just in my inbox this week. But perhaps source could be your life, one day.

>(including I think the Linux >0 distance similar files search crash, finally!) Was that at all related to any of my posts: >>11736 >>11758 >>11797 Because I was having an issue on linux crashing. In the process for searching for duplicates an SQL statement similar to SELECT phash_id, phash, radius, inner_id, outer_id FROM shape_perceptual_hashes NATURAL JOIN shape_vptree WHERE phash_id IN (1, 2, 3); would be executed and cause a segfault, not just for hydrus but anything that could execute an sqlite statement. Apparently Sqlite 3.27.1 (and possibly some earlier versions) had a bug where if the size of a list exceeded two items it just crashed. This appears to be fixed in sqlite 3.27.2. I imagine based on the code I looked at having a search distance greater than 0 would make it far less likely to happen if not impossible.

>>11804 There are quite a few places where the client fetches things with lists up to 256 items long, so if you found that just loading some files and tags was ok, I _think_ you weren't getting hit by that exact issue. But yeah, your posts are the bug I think I fixed. Only affected some Linux users, and I could not reproduce it. I worked one on one in the week with a user who had the crash and we ultimately figured it was a problem with SQLite hanging on to the phash while I did a Hamming Distance search on it (which requires some low level C++ struct calls and then some mickey-mouse CPU-level binary counting). Something to do with memory access violation is my best guess. Python usually can't crash by itself. Previously, I was doing hamming searches interleaved with the sqlite call iterating each row, but when I separated it into completed batches, so sqlite was 'done' with the rows, no crash happened. The 0 search distance could do a direct lookup without the hamming check, and that was running fine. It just seemed to be the combination of iterator on sql results and then low-level access on 'bytes' type response from that that caused the crash. Core dumps suggested the crash was in sqlite code, so I guess it was still hanging on to a bytes buffer or something that wasn't cleaned up. Could indeed still be a (different) bug in sqlite, or python's wrapper for it, but I dunno for real. Let me know how 342 works for you!

>>11801 Owarimonogatari >>11803 wholesome