where can i find this monerod.log : ~/monero/monero/build/Linux/master/release/bin$ ./monerod --log-file monerod.log

in .

If not, there's a remote possibility it puts it in ~/.bitmonero.

yup i found it there (~/.bitmonero), Thanks, I am trying to build from latest commit of master branch of monero i built it successfully but on running it with following command ./bin/monerod --log-file monerod.log --detach

i see a error

how do i share my monerod.log

or if this works :

2020-12-29 04:00:13.520 7f5c10930c00 INFO global src/daemon/p2p.h:63 Initializing p2p server...

2020-12-29 04:00:13.524 7f5c10930c00 INFO stacktrace src/common/stack_trace.cpp:133 Exception: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >

Try asking in #monero after running with --log-level 1 and pasting the relevant log to pastebin.com or similar.

Appreciated v

Hello, what is "COMMAND_RPC_DESCRIBE_TRANSFER" in github.com/monero-project/monero/bl…t/wallet_rpc_server_commands_defs.h (Line 586). What is its purpose? I thought one would only need to provide unsigned_txset in the Request, but multisig_txset is also needed. Is this a multisig-only

request?

It parses a transfer, can be either multisig or signed from a cold wallet IIRC. If it needs multisig, it's buggy.

I see, well if a field is optional it is serialized with KV_SERIALIZE_OPT instead of KV_SERIALIZE. So it looks like both are needed. Do you suggest I not support this in my library?

std::string defaults to empty, so KV_SERIALIZE_OPT is not needed.

Oh I see, in that case it's fine to send unsigned_txset or multisig_txset, but not both, I presume

Is that correct?

Yes. Both might work, but it'll likely pick the one it checks first.

Thanks

I posted this question publicly so others can see the answer in the future:

Getting a strange error from monero-wallet-cli at commit b222188 . Unable to connect to daemon.

debug log says "contrib/epee/include/storages/portable_storage_from_bin.h:168 Too many array elements"

Looks like there is a PR for that: monero-project/monero #7219

oh. Missed it since it was just listed "some people dont want it" :D

Since the cli won't connect i'm sure alot people dont want it :D

zib: 7222 should also help

thx, compilin'

so you need 7220 + 7222

sorry

7219 + 7222

yeah thats what i did. Slow to compile.. ;)

How do I get a + beside my name?

Rbrunner vetted me, and I authored this, which is now in the Monero Ecosystem. Have I earned my keep?

voiced on IRC does not mean anything really

we used to voiced everyone due to spam issues

It adds clout

But I guess it isn't permanent anyways...

nice your code got added to monero-ecosystem

Yeah, Rbrunner gave me great advice, and I built ontop of it. Currently working on reconciling the source code with the documentation (I built all the client-side RPC calls using the documentation).

So there are some commands that I haven't added yet

selsta: same error even with 7219 + 7222

could you post the exact error?

7219 removes the whole check so it is unlikely the same error

also did you rebase release-v0.17 to the latest version?

also did you restart CLI + daemon?

let me do some verification

I did a full wallet scan from height zero with release-v0.17 + 7219 + 7222 and did not have issues

but would be good to know if there are still issues

like you said. 7219 should have removed the error but i'm still seeing it. Maybe the make clean didnt wipe it all heh

selsta: yeah there was some inconsitency, make clean, make again and it works.

sorry for bugging you ;)

@sels

selsta: RE: ccache. Could you give me a branch name or something? I agree with hyc, that it could be linkage problem.

but I'd like to experiment on this.

selsta: Now that I look at the code, your error might be a result of a non-conformant main(), because it misses the argc and argv. While you're there, could you please replace main() with main(int argv, const char * argv[]) ?

sorry, main(int argc, char * argv[])

the compiler doesn't care about that

I'd ask the compiler what it thinks :)

it's always legal in C for a function to use fewer arguments than were passed to it, and ignore the rest.

and the linker won't care either, it just needs to know the function name and address.

My suspicion is, that clang generates a warning of a non-conformant main(), and this triggers a non 0 return code. Possibly because this warning is treated as error now. Who knows without checking it.

which is why we need to see the stderr output, yes

hyc this is C++ we're talking about here, but en.cppreference.com/w/cpp/language/main_function

so int main() {} is also perfectly ok

right

also read the note about implementation-defined forms... lots of systems passed char *env[] as 3rd argument

but again, it doesn't matter, because the C calling convention is defined such that functions can ignore additional arguments beyond what they know about

Well if main() is conformant and it the program returns an integer, then I don't know.

most likely some other env var is wrong in the invocation that cmake spits out

but agai, we can't know without seeing the actual invocation and its output

which cmake always makes so hard to obtain...

ccache is also not something you'd use to produce a release version of a rocket guidance computer.

or even a car.

But in that case, I'd try:

execute_process(COMMAND "${ICECC_CXX_COMPILER}" "${TEMP_CPP_FILE} 2>&1 /tmp/ccache-log" RESULT_VARIABLE RET)

and

cat /tmp/ccache-log

ICECC_CXX_COMPILER -> CCACHE(...)

ryo_ru: If i was on their place i would shit bricks daily from recognising a thought thatactually more inclined and financial backed guys can come and knock you down. So i would hurry for resolution asap

fice: But they are stupid and short sighted, with each release they think it is the last one, pat themselves on the back and declare mission accomplished. Welcome to Monero. Are you tired of winning yet?

my monerod status says 2262781/2262781 (100.0%) but wallet syas Refreshed 2248083/2262781(out of sync)?

aichi-japan: self compiled monero?

yes , master 2bccbee

ok, you need 7218 + 7221

we will merge them today

fine

selsta what's the back story about 7218?

array limit broke wallet sync and wallet changes would have been required

though I wonder if 7221 is enough for wallet sync, can try it I guess

mj-xmr: will try but afaik it failed due to complaining about missing -lc++

How did you figure it out?

hyc: Error: ld: library not found for -lc++

I see

Now I understand the whole conversation :) I didn't have my coffee back then yet :)

So this would mean, that my CMake -> CCache invocation is missing a standard library path via -L

Maybe you can use CMAKE_CXX_FLAGS variable around the invocation, or like hyc said, add the -c option.

I think using the CMAKE_CXX_FLAGS var would make a more versatile test - ie. testing what you would actually get from CMake in near future, after the check is done.

execute_process(COMMAND "${CCACHE_FOUND}" "${CMAKE_CXX_COMPILER}" "${CMAKE_CXX_FLAGS}" "${TEMP_CPP_FILE}" RESULT_VARIABLE RET)

or

execute_process(COMMAND "${CCACHE_FOUND}" "${CMAKE_CXX_COMPILER}" "-c" "${TEMP_CPP_FILE}" RESULT_VARIABLE RET)

Please let me know if it worked. I need a break now.

can a second person take a look at 7221? it works fine but a code review would be good

sech1 maybe :D

maybe

moneromooo: could you rereview / reapprove 7207 after I added vtnerds suggestions?

afterwards we have everything for the tag

Will this be v0.17.2.0 because it contains so many fixes?

I'd prefer it, but we need to get ahold of someone at Ledger to update the Monero App

we can’t call it v0.17.2.0 without breaking ledger support... annoying but that's how it is

Ahh

That’s.. obnoxious

I doubt that the attacks will be over after this release

OK, maybe in a couple hours. I'll need to go read asio docs for this.

soo we still have time for 0.17.2.0

ok thanks

<selsta> I doubt that the attacks will be over after this release <-- agree

mj-xmr: execute_process(COMMAND "${CCACHE_FOUND}" "${CMAKE_CXX_COMPILER}" "-c" "${TEMP_CPP_FILE}" RESULT_VARIABLE RET) works

and CMAKE_CXX_FLAGS not?

<selsta "I doubt that the attacks will be"> Yeah I’m sure we’ll have more to deal with 🙄

reviewed, 7221 looks pretty straight-forward

mj-xmr: no

OK, thanks for confirming

selsta: perhaps with this change the FreeBSD will work as well.

mj-xmr: are you going to PR it?

.merges

.merge+ 7221 7222

Added

I thought it's already PRd. If not, then sure. I have 30 minutes left until I leave.

It is not PRed yet

I will want to push one more change after the successful build, to see how FreeBSD reacted.

But thanks for the quickest review, I've ever had :)

*empty change I meant

selsta: please see my comment at 7226

We "fixed it" by shutting one eye :) No J/K. This is not an actual fix.

I'll have a closer look tomorrow. At least we know what the cause is.

mj-xmr: ok, it used to work fine on mac, it stopped working with a recent compiler or cmake update

No surprise for me.

selsta: approved

thanks, please also the branch equivalent 7208

luigi1111w: do you have time for merges?

also ping Snipa :)

afaik we have everything for a tag now once the current merges are done

.merges

Kk, will scan through shortly.

Just on morning standup right now.

nice

Merged

ty :)

I guess let's wait a bit before tag

I just built release-v0.17 after those merges and am getting stack traces: paste.debian.net/1178785

Seems to be working still but figured I’d share in case its helpful

Happy to debug whatever would be helpful.

Seems boost related, maybe? I’m compiling with 1.71 IIRC, double checking now.

...randomx...LargePageAllocator...allocate...

Reboot and try again. Or don't :)

It's probably one of the most common traces now.

Ah, good to know, thanks

I’ll try that

Probably because I just had xmrig paused and not closed when starting monerod, I suppose?

Yeah no trace after restart

Sorry for the bad report :)

If xmrig is paused it still has memory allocated so monerod didn't have enough RAM to create RandomX VM

Yeah thats what I figured

luigi1111w: are you available later for tagging v0.17.1.8?

<sech1 "If xmrig is paused it still has "> Odd, that stack trace started occurring again as soon as I started up XMRig.

It probably means you don't have enough RAM for the amount of mining threads you are running, in addition to monerod doing its own randomx thing.

You probably need to allocate more huge pages

Thus running out of huge pages.

I've checked the code and this exception should be caught inside RandomX lib and then the VM should be created without huge pages

so monerod shouldn't crash

It's more like a warning than an error

I wonder what changed. All of my Xmrig and monerod config are the exact same. No RAM amount changes, still 32GB

I can try bumping huge pages and see what happens.

you've run out of available huge pages. You could try to increase vm.nr_hugepages

I forgot I never actually set it in sysctl.conf, and relied on XMRig to set.

I’ll try increasing from the default that I think XMRig is setting.

Any idea whats appropriate for 32GB of RAM?

1280 is the recommended by XMRig

xmrig maybe does set them, but monerod doesn't ;)

Weird I’ve never seen this issue before now, but manually setting hugepages to 1512 seems to be working so far

So if you plan running several randomx apps, set them manually to the appropriate amount.

Thanks :)

hhi

selsta yes

luigi1111w: ok please tag whenever you have time

v0.17.1.8

and once you tagged please ping me

can someone point me at the gitify docs please?

never heard of gitify

contrib/gitian if you meant gitian.

yes thank you!