[bug] investigate issues with qa on unsupported hw #3305
Comments
|
following up on this, it appears the tests only error out when attempting to run the full test suite a la |
|
These look like timeouts to me, but I'm surprised they'd time out on (presumably) strong hardware like an M2. |
|
indeed, i was surprised too but it's definitely possible to replicate. i need to do a deep dive. |
This comment was marked as outdated.
This comment was marked as outdated.
|
I've found some issues in However, after compiling with a working wallet, I cannot reproduce your issue using #3301 with or without the ARMv8.2 crypto routines. All tests pass for me in 5 out of 5 runs right now for each flavor. |
|
interesting. i managed to dl 5.3 using brew (brew install berekely-db@5) but did a work around in renaming the directory to omit the @5 which initially caused it to not be picked up in configure.ac. this was the configure command i used: outside of that i suspect it has something to do with m2 specifically. |
I'm proposing a fix to the brew mess in #3308 - works on both my M1 and x86_64 macs.
Can you try without experimental features? (Didn't make a difference for me tho) |
|
yeah let me do try without experimental features and then i'll try again after rebase #3308 on top. |
|
strange. i thought i had solved my python version issue (which was set as 3.10) but just got this after rebasing on #3308 so will have to figure that out after dinner, and yeah compiling without experimental didn't do anything unfortunately: |
|
nevermind, running it now. |
|
|
going to try the whole test suite again with |
|
Those all look like race conditions. To make sure that these are errors in the test and not the C++ code, would you mind doing this with |
|
yeah absolutely, let me try rn. also want to note that the results from using parallel last night on the full test suite failed as well. |
|
so i'm unable to build using |
|
this was noted above in the config.log: so not sure if i should attempt to use 1.63? or bump to 14 or...what's going on here. |
I'm running into the same issue with clang, it's caused by Do we agree that none of this is caused by #3301 though? Or do you have remaining reservations? |
following patch fixed it for me: diff --git a/src/sync.cpp b/src/sync.cpp
index fce57f1df..6cb3d6713 100644
--- a/src/sync.cpp
+++ b/src/sync.cpp
@@ -11,6 +11,7 @@
#include <boost/foreach.hpp>
#include <boost/thread.hpp>
+#include <set>
#ifdef DEBUG_LOCKCONTENTION
void PrintLockContention(const char* pszName, const char* pszFile, int nLine)I'll deliver a bigger PR to resolve this soon, taking a little more time because it turns out there are also 2 types of undefined behavior in this code and it is seeded with unnecessary boost macros. |
no reservations re #3301, i think that's good to go. |
so that fixed it :) also disregard changes to depends, still a work in progress re openssl :/ |
|
edit: minus my depends stuff https://github.com/xanimo/dogecoin/commits/0c057ba35d712f2e098e084604748ca403ac1181 |
|
Okay. It's sort of unfortunate that the entire test ran without errors. Is bumping boost to 1.70 / patching OpenSSL in depends related to this issue? To x-compile or to locally build? |
i couldn't get through depends :( it failed on boost 1.63, hence the bump, and then failed on openssl, even after adding the patch to support darwin64-arm64-cc: so that said, everything i did to pass was only up to wip: make DEBUG_LOCKORDER work with clang on the edited commit link and by running: |
|
i did however upgrade to mavericks last night and noticed that 8 prompts popped up to allow incoming/outgoing requests to |
|
oops i meant ventura. |
|
MOST IMPORTANT Q: How do you want to proceed testing THIS issue? Re: depends.
Depends is maintained with a focal x86_64 guarantee only at this time. If you really want to support macOS as a depends / x-compile build host there are a ton of patches to the depend system itself to pull first because there are known conflicts between the x86 host x-compile configuration and using a darwin build host. I personally think it's better to make that work with 1.21 than with 1.14, but it is not impossible to do the latter. Boost upgrade could be interesting, depending on what it brings in terms of fixes. I'm assuming you and yours are not building any new features that actually require 1.70 or later, with all the boost hate being voiced? Re: allow networking
Interesting. I think I have never seen such thing, but I am withholding one patch at the moment so that I can test the macOS doc on multiple versions of arm and x86 now that there's an actual working build, before I mark as ready. Can you open a new issue with the details? |
this issue re qa can definitely be closed.
yeah no me and mines aren't doing nothing, i honestly could've just applied that patch to 1.63 probably but i have no qualms using it but would've failed on openssl anyway and yes i saw red x's across the board when i pushed the previous runs so i think i'll put any upgrades on hold.
yeah sure, it's really just the firewall asking if i want to allow an app through but if you need details i can open an issue for sure. otherwise feel free to close this as my issue is solved or i will when i get back from my walk to the grocery store. <3 |
Wait... How did we fix the test races? Adding |
|
i didn't use the patch, just cherry-picked xanimo@ca3675e but this one just solves |
|
hmm ok nevermind. going to run with |
|
ok so i've ran the test suite 6 times and failed on |
|
i think that |
|
I ran both The interesting thing about both errors though is that they are caused by the expected time it takes to process a certain action to complete being exceeded, which is odd because my M1 However, since running
|
|
agreed and a relief you were able to reproduce. i'll take a look at implementing a |
upon reviewing #3301 and #3188 on arm64-apple-darwin (m2) i found there are 4 tests failing qa. opening this up as a reminder of things to come re our qa test suite running python 3.11 (and ofc on unsupported hw). here is my log:
https://gist.github.com/xanimo/5271fc15bf21cd60655d4c68bc85aa60
The text was updated successfully, but these errors were encountered: