<ooo123ooo1234[m]> "And are there any other reason..." <- here we go: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/319

as expected

"... simple mode" by implementing a trusted community node system" incompetent to solve problem with proper code -> add trusted nodes

bs

"Create a more thorough UI for warning users of GUI mode of high fees" instead of removing fee prediction unsuitable for decentralized untrusted env, bs

"Draft a formal Levin/Cryptonote protocol specification" it's impossible without code reading which is already hard for some reason, unreachable goal

"Continue to remove dead code" start to read not dead code would be better, but it's hard for some reason; bs

"Misc developing / reviews" without code reading ? how is it possible ?

bs

"Unclear protocols cause bugs and choke out emerging projects which wish to incorporate into the ecosystem. " code written by people who don't read code leads such bugs

It's literally this en.wikipedia.org/wiki/Influence_peddling

Users suffer from incompetent developers and they are using it as a leverage to do more bs work: monero-project/monero #8298

facepalm

"All of these points do not directly affect the end-user experience but will ultimately improve the developer experience, reducing friction in the future, contributing to the long-term health of the codebase." incompetent developer is going to improve long-term health of the codebase without reading it; and state explicitly that end-user isn't the target

facepalm

"It's always a nice thing to have your code compile on all your targets." warnings != can't compile, the code can be compiled; as soon it can't be someone would just submit minimum patch to fix it

instead of doing all that noise just for the case of work simulation

"monero-project/monero #8307" this is a removal of something that is already implemented and could be used

and it was merged already

And thin here "monero-project/monero #8335" you tried to remove create_ec_ssl_certificate

which not only could be used, but it's even better than RSA in some performance benchmarks

"monero-project/monero #8335#issuecomment-1128071304" and this comment was about stopping you from removing arbitrary things left and right

"... @hyc suggested the idea while I was working on moving certain parts of the codebase to OpenSSL 3.0" and you wrapped it into this

So it shows neither you, neither your PR reviewers, neither code merger have any knowledege about code base

full chain is compromised

facepalm

And these removal balanced with "more placebo test, more trivial docs, relocation of code into separate files"

Do you really believe it helps ?

And also people who don't write code like plowsof are calling this as "talented dev"

double facepalm

and then UkoeHB asks me to be decent and don't ask critical questions in such environment

Are you really sure that I'm wrong ?

Is master supposed to build currently?

<admin_> "Is master supposed to build..." <- yes unless you have unexpected environment setup, but in that case you can use docker with depends

Yes. If it doens't, paste the error on paste.debian.net and the URL here.

Sometimes, it doesn't due to several patches being merged in one session, and they conflict a bit. Typically very easy to fix.

Errors: basilisk-design.co.uk/pastebin/paste.php?id=23

Blocked by captcha, but I'm building here, and I'll see if I can fix once I get to the error.

"monero-project/monero #8211/commits/801568d0c6dadfcf4992eaf7ed5565e5682ad248" this change

Pastebin: paste.debian.net/1241249

Deleting captcha infested account :(

Odd one. What OS ?

And I've just built levin_notify just fine, without that error.

OS: Slackware x64 14.2

v0.17.3.2 builds just fine.

$ ./usr/bin/monerod --version

Monero 'Oxygen Orion' (v0.17.3.2-release)

Good data point.

The relevant change I see if the switch from byte_slice.

Looks a bit annoying to cherry pick though.

I'll wait for a tag or branch for v0.18 :)

Sorry, no quick fix here then. We might have to wait for a coder who has the problem.

They key problem is in "no known conversion for argument 2 from ‘const __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >’ to ‘std::basic_string<char>::iterator {aka __gnu_cxx::__normal_iterator<char*, std::basic_string<char> >}’"

aka the compiler couldn't convert const char* to char*

Actually, try to revert 801568d0c6dadfcf4992eaf7ed5565e5682ad248

I would try to rewrite "m_cache.erase(m_cache.begin(), result[0].second);" as "m_cache.erase(0, result[0].second - m_cache.begin());" or something like that

That patch says it "refactors" but there's no factoring I can see. Sigh.

sech1: I would try to firstly identify the source of problem instead of doing random bit flipping

I'm on gcc 5.5.0 if that means anything.

I hate how people use "refactor" for "rewrite how I like" nowadays. Factoring is taking various similar/identical bits of code and merging them.

moneromooo: +1

ooo123ooo1234[m] Did you read what I wrote? I found the source of problem - const char* vs char* incompatibility

older compiler doesn't have enough definitions in headers probably

oh yes, 801568d0c6dadfcf4992eaf7ed5565e5682ad248 is the culprit

"However, this in not necessary as of C++11, so I removed the conversion

altogether."

I'm not an C++ expert, is it true? gcc 5.5.0 does support C++11 though

sech1: Don't underestimate, you're pretty C++ expert in current environment

"iterator erase( const_iterator first, const_iterator last );" is available since C++11, the compiler should've used that instance

Various compilers have bugs and "missing bits" in their standards compliance, especially when they're building up support so it wold not be super surprising.

converting first argument from iterator to const_iterator should've been done implicitly by the compiler

so better advice to admin_ would be to update the compiler

gcc 5.5.0 is the latest on Slackware 14.2 - I'll try on Slackware 15.0 (gcc 11.2.0), as soon as I have made install packages for the dependencies not available standard.

Building with gcc 11.2.0 is a lot more noisy than gcc 5.5.0 - The amount of warnings are scary.

Building master on Slackware 15, gcc 11.2.0 was successful, with a lot less warnings, compared to building release-17.

Only missing dependency was unbound.

$ ./usr/bin/monerod --version

Monero 'Oxygen Orion' (v0.17.0.0-6e60919e6)

<TrasherDK> "Building master on Slackware 15,..." <- Do you still have access to that env with gcc5 ?

<sech1> "so better advice to admin_ would..." <- Not better since it isn't related to compiler version

Proof?

<sech1> "ooo123ooo1234 Did you read..." <- It isn't the source of problem

sech1: I have, I have, wait a bit

mirrors.atviras.lt/slackware/slackw…2/patches/source/gcc/gcc.SlackBuild - gcc package in slackware14.2

"gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html" info about gcc configuration for versions starting from 5.0

So it is about compiler version

"--with-default-libstdcxx-abi=gcc4-compatible" this flag during gcc package combpilation adds macro -D_GLIBCXX_USE_CXX11_ABI=0 which disable some features of c++11

"--enable-libstdcxx-dual-abi" but this flag is enabled too, so it's possible to set manually that macro to default value 1

and everything will work as expected

including -std=c++11

Btw, that macro breaks build for even the latest gcc version

In essence it's about C++11 support

sech1: So you are not right

sech1: In essense it's about knowledge of your environment

The code that triggered the error is C++11 compliant, so no need to fix it

sech1: yes, that code is compatible with c++11

If it's not hard to support more compilers, why not. As long as it's not MSVC :D

sech1, "godbolt.org/z/e5s7ohWMc" proof

<sech1> "In essence it's about C++11..." <- If this would be a competition then I would won.

Who cares, I care about the code more. If it's standard-compliant, fixing of any compilation errors in exotic environments should be done outside the code - by whoever is compiling it.

Or we'll end up with a million more #ifdefs and macros

Plus, it's C++11 we're talking about. It's been 11 years, we can just ignore non-compliant environments

we moved to c++14

sech1: Look I've already suggested compilation via docker in the fist step - initial approximation from me

your suggestion to change that line or revert that patch - further approximation by you

and just to add 1 macro which is absolutely safe in that environment - the next approximation from me

My suggestion was made before I learned that the code was in fact correct

In this particular case even precision of initial approximation would be enough

But in everything related to decentral protocol I want as detailed as possible, since it's very important

now that we updated the macOS SDK we could even move to C++17 without issues but that's something for the future

And in cryptography the devil in details, it's also very important

This is why we do audits for all cryptography implementations

lol rip multisig

sech1: No. You can't audit code without learning it. If you don't believe me then let's setup competition with auditors

I'm ready

hahahaha

Did you remeber what auditors find in randomx ?

nothing

What? Auditors _do_ learn everything about the code they audit

it's part of their job

plus they are selected so that they already have necessary background knowledge

sech1: They can learn everything within limited scope

But they will never have time for learning full graph of code without spending on par with people who developed it

Auditors did find a number of issues in randomx

sech1: Call at least 1 which is critical

does every audit _have_ to find something critical?

you're welcome to read through: github.com/tevador/RandomX/tree/master/audits

sech1: I've read it at that time, no need to repeat

sech1: Critical for the goal of project. This is the only thing everyone should optimize code for

And it's reasonable to check whether code achieve the goal

We've been checking it for 2.5 years so far (with RandomX)

sech1: I mean if nothing critical is found then work is done properly. And the goal of auditors is to check it.

sech1: If there are a lot of resources to check not critical things too, then great. But it's not necessary

I am on the latest version of monero-javascript. I get this error recently when trying to create transactions

anyone has an idea where I could look next to troubleshoot?

You did not paste the error. I assume some picture that got filtered. Setting log level to 2 might help.

Uncaught (in promise) RuntimeError: Aborted(Assertion failed: R == dbg_R, at: /Users/woodser/git/monero-javascript/external/monero-cpp/external/monero-project/src/crypto/crypto.cpp,450,generate_tx_proof). Build with -sASSERTIONS for more info.

it looks like wrong secret key

was provided

That looks like passing a keypair that's not consistent. Is there a stack trace ?

I took a look at this but I have no idea what it means to be honest. I fed it the typical info: "{accountIndex: 0

address: "5F2AGUyXjR3bvX38GaAsARaQ1exeBCVkUbPTfGssBfXQ5VPor4eA144YpUE7FNg5bLcpEuehNne23MkG8ZMCkPEegmCBqDwCTM3QChKCmS"

amount: "250000000000"

relay: false}"

Also, is this a view only wallet ?

This should be a normal wallet similar to the one I created before. creating transactions and relaying them worked before but it stopped working now. There are many degrees of freedom to debugging this. Because monero-javascript versions changed in between and I worked on other parts of the app in between.

I have a javascript stacktrace but its probably not of much help

All I know is it fails somewhere after createTx(config) is called

try git bisect

(if you use git)

are you able to confirm the previous version of monero-javascript works with your current setup, to isolate the issue to the last version?

if you're able to run the code from the terminal, you'll usually get a more informative stacktrace than the browser

before that I was on v0.6.4 and it also didnt work. It was the same error. I thought the wallet might be corrupted so I made a new wallet and got new money from the stagenet faucet. Everything worked. The transactions arrived the balance got added to the wallet but I can still not createTx without issue. In the beginning I thought its because I pass the txconfig from parsepaymenturi to createTx but with the object like above it also does

not work. I dont think its coming from updates in monero-javascript.

I am just looking for some inspiration 🙂

spirobel[m]: 1 detailed log would be better than 1000 of words

Well, the secret key does not match the public key AFAICT. You could log both, and call secret_key_to_public_key in a temp program to see if they match.

I *think* secret to public is just mul G...

the secret key should be in the keysData of the wallet file, right?

What's interesting is where this is called, which is some C++.

Dunno. That's what following the stack trace will tell you.

Probably, though. Unless it's deduced on the fly from kes in the wallet file.

the issue is that I dont really have the stack trace and it would take a lot of time to get it. I am just calling a javascript lib after all. My guess is that the spend key got corrupted. The view key is also in keysdata, right? so it seems like some part of it got corrupted and openwallet still worked ...

so probably the spend key just got lost somewhere

selsta: c++17 isn't fully supported yet by even clang (exotic features like pmr are unsupported)

You are calling... a very high level function, right ? If so, there's a lot of call stack betewen that and generate_tx_proof.

moneroecosystem.org/monero-javascript/MoneroWalletFull.html I am calling createTx here

If you can repro without javascript (ie, load that wallet with monero-wallet-cli) then you can use gdb to break on the assert, then see the stack.

UkoeHB according to en.cppreference.com/w/cpp/compiler_support indeed clang doesn't fully support C++17, but GCC does

>Clang 5 and later implement all the features of the ISO C++ 2017 standard.

selsta: not the C++17 STL though

although the missing bits don't seem too important

<spirobel[m]> "the issue is that I dont..." <- "the issue is that I dont really have the stack trace" it must be fixable somehow for web development, otherwise web dev is absolute nightmare

<UkoeHB> "selsta: c++17 isn't fully..." <- Reduction of target platforms makes writing code easier, not upgrade to some c++ standard

Which isn't compatible with goal of this project otherwise we're targeting linux users with rolling distro

does anyone have reorg logs that go farther back? monero-project/research-lab #102#issuecomment-1129711324

Okay I just did this: Window.wallets['monerochans stash'].isViewOnly().then((x)=> console.log(x)) and it returned false. so it seems like it is opened as a normal wallet.

things we can try:... (full message at libera.ems.host/_matrix/media/r0/do…400c8afe4f2259daddd21bb86c96623cd3b)

UkoeHB: Current p2p network is very centralized. Logs can't be used as a justification for random bits flipping in protocol

part of p2p network with mining nodes which are directly related to number of reorgs

other nodes have almost 0 impact on mining

* things we can try:... (full message at libera.ems.host/_matrix/media/r0/do…f0b61d50e1b0383f1405cbbd3b05e06ce25)

ooo123ooo1234[m] 10 blocks lock time was randomly chosen to begin with

and reorgs can be seen by every node, so all logs are relevant

sech1: I mean it would be better to do more analysis for the next change even if prev approximation (10 blocks) was not analysed properly

so we need logs to have data about historical reorgs

I definitely remember seeing reorgs bigger than 5 blocks some time in 2019 or 2020

sech1: I mean logs reflect current p2p network of miners (minexmr 40%, ...) which is closer to not ideal state of network

minexmr runs many nodes in different parts of the world though, so it's multiple miners from network's perspective

same for other big pools

And since the goal is to make it more decentralized synchronization latency will be bigger, not smaller

time to propagate a block is a measurable metric

sech1: This network is controlled by single in which case it's reasonable to connect all owned nodes to each other for better connectivity

if we figure out that it takes < 10 seconds (for example), we can estimate the probability of network mining 5 blocks in those 10 seconds

If the same nodes would be run by untrusted parties, situation would be worse

sech1: Yes, I'm sure that proper measurements will prove my point

I was talking about block propagation (re minexmr as single/multiple miners)

what really matters is block propagation to big pools' nodes

> <@woodser:haveno.network> things we can try:... (full message at libera.ems.host/_matrix/media/r0/do…c481ce504bdfac042131f62ebe2b08b196d)

alt chains won't get propagated, so you'll only get an alt chain if you're connected to a node for which that chain is currently the main chain.

So you probably do not have all the alt chains in your log range.

right, and alt chains get created because the rest of the network doesn't propagate their blocks quick enough

my node is well connected

sech1: Yes, but I went further and there are some edge cases that could be abused in general case

10 blocks is also a protection against someonw who'd keep a local chain without propagating, if they have 50% or close.

So it requires some modelling of network, choosing parameters, and proving that it's secure within it

I'm not clear when it's worth "starting over" while you have more than 1 and fewer than 10 on your way to a 10 though.

iirc there's a paper that looks into this kind of "selfish mining"

So you would never see those "temporarily withheld" chains now because there's no point (assuming 10 blocks is enoiugh of a deterrent).

But if the lock goes low enough that some people think it's worth trying, then you'd likely get the attempts made, and thus have an inordinate number of chains of that length compared to what you saw before.

basically it's about the odds of you finding a block with a higher pow value before the rest of the network can find the next block on top of the chain tip

merope: There are many projects with different consensus protocol architecture which can be used for the sake of learning

not only that paper which is very narrow scope

High hash rate miners currently don't try to build on their blocks, and will update to the current head, resetting their "local height".

@ooo123ooo1234 - Slackware 15 comes with gcc 11.2.0 - Slackware 14.2 comes with gcc 5.5.0

moneromooo: +1

moneromooo I don't see the incentive for big miners to do reorgs specifically bigger than the lock time. They could just do a reorg of any size to orphan other blocks and get all rewards to themselves.

(also available on moneroresearch.info

)

sech1 but that is effectively a 51% attack, no?

It allows them to render any tx spending early (right after 10 blocks) invalid. One of those txes might be one of theirs.

ah, so double spending

then we need to calculate probability that a 40% miner can build an N-block chain faster than the rest of the network

I suppose that should really be "more than the number of confirmations your recipient uses" though.

Which might not be 10.

Kraken has 15 confirmations for deposits

In any case, it allows for invalidating random txes which either spend asap or randomly use an extremely young 10 blck fake out. Less annoying though.

xmr.to accepted even 0-conf transactions up to 0.1 BTC equivalent

<TrasherDK> "@ooo123ooo1234 - Slackware 15..." <- monero master should be compilable on slackware 14.2 with -DCMAKE_CXX_FLAGS="-D_GLIBCXX_USE_CXX11_ABI=0"; if it still makes sense you can test

sech1: Any such number has corresponding probability of double spending.

XMR merchants can set their own confirmation limits which can be higher (Kraken as example)

it's all about acceptable level of risk for each XMR recipient

sech1: Yes, but higher confirmation limit means more troubles for users

And the only way to allow safely small confirmation limit is to learn how to calculate risk proprely -> analyse protcol -> improve it -> objectively smaller risk in the worst case

Both gcc 5.5.0 and 11.2.0 support c++ 11,14,17

sech1: There are of course limitations added by hardware of network participants, but there is still huge room for protocol improvement

TrasherDK: Did you check link about gcc dual-abi ?

UkoeHB, noncesense lab folks should have info on altchains. ping neptune isthmus

<ooo123ooo1234> Yes, adding the flag didn't help.

cmake \

-DBOOST_IGNORE_SYSTEM_PATHS=OFF \

-DCMAKE_BUILD_TYPE=static \

-DCMAKE_CXX_FLAGS="-D_GLIBCXX_USE_CXX11_ABI=0"

TrasherDK: Oh, sorry. IT must be 1

:)

typo

HenryHollingwort: where did you download monero?

hi everyone, i tried to compile master under mysys2 following the instructions and the build succeeded (seemingly) but when I go to run the binaries I receive the following error. Should that dependency have been statically linked?

I cloned master directly from github

(using git cli)

did you make sure to use the mingw64 msys2 shell?

don't use the git shell

what did you enter for make?

that shell is opened with the following command: "C:/msys64/msys2_shell.cmd -defterm -here -no-start -mingw64",

make release-static-win64

it seems to find the libunbound library :/

we removed the unbound submodule in master, might related

<ooo123ooo1234 Okay, I survived the 74% crash from before, but got a new one paste.debian.net/1241289

HenryHollingwort: did you start monerod from explorer or msys2?

from explorer

check if starting from msys2 works

yep that works

don't know a fix yet, have to try a bit around myself

should it work from explorer? I assume that mysys2 adds some stuff to PATH and then the dll is dynamically linked so it works from there? idk i don't know much about c/c++ building and native stuff haha

it should work from explorer

at least when you do release-static

yeah that makes sense

maybe a dumb question, but should running the current release in --testnet work (well without me and whoever is running the old version 'forking off')? The reason I ask was because I was working on the monero bounties bot and all my transactions seemed to not go through and then I remembered reading a post of reddit about the testnet having forked to master to test the upcoming release. When I realised that I assumed it was

probably why my daemon seemed to be acting funny

some cmake changes required probably, will take a look later

testnet requires master for now

release-0.17 will be on the wrong chain

great thanks, I thought that was the case

And my testnet daemon is down until I can build again :(

HenryHollingwort: can you tell me the path on Windows for monerod.exe?

C:\msys64\home\Henry\monero\build\MINGW64_NT-10.0-22000\master\release\bin

ty

I remember having similar .dll issues when compiling on Windows, and I somehow fixed it. I'll check in the evening when I'm back home.

I know nothing but just hand a little look around trying to see if anything obvious shows up and

github.com/monero-project/monero/blob/master/CMakeLists.txt#L1049 thre is a "-static" flag which the comment says will make the build 'as close to fully-static as we get' which makes me think that the '-static' should show up in the command that ultimately gets executed? but I don't see it in the makefile under /release (the build dir)

release-static-win64:

mkdir -p $(builddir)/release

cd $(builddir)/release && cmake -G "MSYS Makefiles" -D STATIC=ON -D ARCH="x86-64" -D BUILD_64=ON -D CMAKE_BUILD_TYPE=Release -D BUILD_TAG="win-x64" -D CMAKE_TOOLCHAIN_FILE=$(topdir)/cmake/64-bit-toolchain.cmake -D MSYS2_FOLDER=$(shell cd ${MINGW_PREFIX}/.. && pwd -W) $(topdir) && $(MAKE)

-D STATIC=ON should do the magic

unless the -static was what caused STATIC=ON i dunno :\ like I said I really have no clue about this kind of stuff

the makefile calls cmake which again calls make

it sets "-static" there

make first time creates that makefile in /release, that then calls make again but at that stage STATIC is set so it will add the -static flag during the actual compilation

got it thanks

i've got to head to bed, but let me know if I can help with anything later :) even if it's just testing it again locally

fyi, my linode monerod has ~5 years worth of logs, 1082 reorgs. all but 4 had size 2, those 4 had size 3.

libunbound-8.dll => /mingw64/bin/libunbound-8.dll (0x7ffba0860000)

<TrasherDK> "<ooo123ooo1234 Okay, I survived..." <- "ftpmirror.infania.net/slackware/sla…2/patches/source/gcc/gcc.SlackBuild", "# which will then require rebuilding all C++ libraries. That is, if there's any benefit." boost was compiled with old abi therefore linking failed. Then it's the case from the comment from slackware gcc package. Upgrade to slackware 15 is easier to do than recompiling all monero deps

with new abi within 14.2. So that refactoring made incompatible your env with master.

Yet another reason C++ sucks, compiler-version-dependent ABI...

hyc: yeah, yeah. I remember you were talking about it at least once here.

yeah, definitely not a new topic

C is not much better in terms of ABI: gankra.github.io/blah/c-isnt-a-language

meh. the arguments in that writeup are mostly immaterial, don't affect the majority of C or non-C progreammers

because in C only the language implementers need to know the fine details of the ABI

in C nobody else needs to be aware of them. in C++ most people don't know the details but they bump into the problems all the time.

he bitches about __int128 as an example. which is such an edge case on its own, nothing in reality uses inegers with 128 bits of dynamic range.

but mostly, "C ABI" is wrong perspective. The "ABI" is an assembly language calling convention. C was a user-friendly frontend to assembly language.

Language standards committees have lost sight of this fact.

his diatribe about parsing C header files is a misrepresentation, most of the complexity of definitions and includes is handled by the C preprocessor, not the compiler. the preprocessor isn't even a C-syntax-aware program. it's just a text processor like m4.\

__int128 is a popular GCC extension. Many scientific programs use it (those which don't need more than 128 bits). Even p2pool uses it for 128:64 division and 64x64->128 multiplication

those uses are self-contained tho, so you never bump into the ABI boundary

sech1, did you check thesis of that author ?

I'm reading 4.2 Paranoia

now

"Paranoid solutions give the compiler and programmer rich information to optimize the program with. " hmm, rust lang is for paranoid solutions

If I would have unhealthy paranoia then I would love probably. But It looks like a waste of time for me to add all those specifiers with the hope to avoid memory unsafety.

reg Jeffs ccs proposal - i have edited / disappeared into the hedge like homer'd my comment. We need actual developers to read it and offer opinions.. we also try to discuss ccs ideas in community meetings (not this sunday , but next) x

"... Control is absolutely the greatest strength of naive interfaces. They empower excellent programmers to produce excellent code where it matters." it looks like exactly the case of lmdb or any other low level staff

e.g. firmware

s/staff/stuff/

is there a way to set a password for specific accounts within a wallet?

no

<spirobel[m]> "> <@woodser:haveno.network..." <- spirobel:... (full message at libera.ems.host/_matrix/media/r0/do…087c79decb82a704b2b24b368f43b7d10ac)

selsta Monero binaries compiled in mingw64 have dependency on libunbound-8.dll on my system too

yes, I reproduced it on CI, but didn't find a fix yet

As far as I can see, libunbound package in mingw installs only dll and headers

I saw .dll.a

that's what we get for preferring pre-installed libunbound to our vendored source

dll.a is just an import library for a dll

.dll.a is just declarations for dll functions

yes, import library

hyc: the vendored one was extremely outdated and full of (security) bugs

why didn't we just update it then?

I solved this problem by just adding the path to libunbound-8.dll to the system search path and successfully forgot about it :D

hyc: monero-project/monero #7773

this is also the reason issue #8322 exists

gitian builds don't have this problem

so main problem is supporting autoconf from cmake?

(with the dll)

i mean the reason why we had a vendored unbound in the first place was because we applied our own security patches

gitian builds libunbound explicitly

but our own unbound become outdated and unmaintained

yeah. I recall we had that wonderful problem where unbound was writing errmsgs unconditionally to descripter 2 and overwriting the blockchain DB

and I tried autoconf from cmake, but it was a mess getting it supported for all OS and cross compiling

so I removed it completely, and everyone who wants to compile static bins without depends should deal with it themselves

heh, ok

I guess since we have depends working we can ignore it

manually compiling static unbound should be enough I think

yes

without any extra frills. like macosx's libunbound using libnghttp2

and setting UNBOUND_ROOT

sech1: do you know why some mingw packages contain static libs and some don't?

ask whoever made a specific package. I guess it's just how it is in open source

true :P

so the quick fix for me would be to compile latest static libunbound locally and make cmake find it?

yep

you might also have to compile expat, not sure

the lowest effort would prob be to cd contrib/depends; make HOST=x86_64-windows-pc (or whatever) unbound

then copy the resulting static libs to your windows box

at least I did that here monero-project/monero-gui #3696

which was copied from depends

HOSTS="i686-w64-mingw32 x86_64-w64-mingw32"

that would ensure you get one built correctly anyway

ooo123ooo1234[m]: can you help me with paste.debian.net/hidden/29afb4ff ? I have this plus the binary, I want to find the code part where the segfault occurred. Do I have to use addr2line or something else?

it's the first segfault in many months so I'm curious

ip is the place you want. I expect the first number is the address, though from the wording I'd expect it to be ip.

addr2line should work from that ip if you're lucky.

(ie, if built with enough debug info)

ip/eip might point to the insn right after the one that borked, I can never remember.

If it doesn't work, you theoretically could rebuild with all debug info, without changing other flags, and grep the "Code" bitstring to find the new address the "f3" corresponds to. A bit of a pain in the arse though.

And that's assuming extra debug info doesn't change the emitted code.

You did check if there's a core ? It'd simplify a lot :D

ulimit was unfortunately set to 0

it did say core dumped but i did not find anything

<selsta> "ooo123ooo1234: can you help me..." <- the binary is unavailale

ooo123ooo1234[m]: gui.xmr.pm/files/monerod_copy

Anyone else getting "Exception: boost::wrapexcept<boost::bad_weak_ptr>" with the new testnet code ?

i didn't get it yet

full log?

I'll post an issue on GH

Bad_weak_ptr sounds like it could be related to that segfault issue

my segfault wasn't testnet

these uncaught exceptions show up from time to time, don't know about that specific one

Okay it's not just testnet, it shows up on all 3 networks for me

<selsta> "it's the first segfault in..." <- github.com/monero-project/monero/bl…rnal/db_drivers/liblmdb/mdb.c#L3080

hmmmm thanks

also ping hyc ^

found interesting repo dedicated to lmdb

probably all of them already fixed in upstream since 2019

<jeffro256[m]> "Bad_weak_ptr sounds like it..." <- "monero-project/monero #8341", "It occurs every ~15 seconds while running monerod, no matter the network:" Open debugger and check what's going on there

if it's so easy to reproduce

<jeffro256[m]> "Bad_weak_ptr sounds like it..." <- It isn't related

I checked my logs and didn't see it but I'm not sure if depends binaries even print stack traces to logs

ok, should print them

<jeffro256[m]> "Anyone else getting "Exception..." <- Did you check history "github.com/monero-project/monero/issues?q=is%3Aissue+bad_weak_ptr+" ?

> > <@jeffro256:monero.social> Anyone else getting "Exception: boost::wrapexcept<boost::bad_weak_ptr>" with the new testnet code ?

>

> Did you check history "github.com/monero-project/monero/issues?q=is%3Aissue+bad_weak_ptr+" ?

Only for open issues, will take a look

Doesn't seem like they got too far

There's a ton of boost::shared_ptr 's in the tcp server code so it could be a lot of things

monero-project/monero #6473 has some people reporting the same

but should be fine to keep your issue open jeffro256[m] as they are all closed

moneromooo The first trace is not at all similar to my trace, so it's probably unrelated. The second trace looks a lot more similar but moneromooo says its fixed, which it appears not to be

* @selsta

It appears to originate from safe_shared_from_this() in abstract_tcp_server2.inl