woodser: does this work ? Looks like in the end it's all that ought to be needed for mlock: paste.debian.net/hidden/4c51cad5

<woodser> @moneromooo the patch does not prevent what is commented out in this diff from executing, and so still hangs

<woodser> github.com/monero-project/monero/co…ff-c0db3a8a2c8e06418d35f3da238b0b2a

Get me an all thread stack trace please.

Hrm. Can you actually do that with js ?

<woodser> that would be really nice but I do not know how to do that from js to webassembly

<woodser> I will research

I guess we can define out pretty much everything, but if possible I'd prefer to understand where it's hanging.

mlock is undefined on windows, and that one doesn't hang AFAIK.

<woodser> I recall from building and debugging that CRITICAL_REGION_LOCAL seemed to be the problem point

Did you change that ?

<woodser> yes

Did you change anything else ?

<woodser> yes. all changes to mlocker.cpp are in the diff I linked

What you linked doesn't include any changes to CRITICAL_REGION_LOCAL.

So you didn't change it, you just commented out the calls to it ?

<woodser> right

Plenty of other places in monero use it. Do they hang ?

<woodser> none of the others have needed to be commented out, but I’m also not using the included the http client, so I’m not certain it’s being called elsewhere

Or you can try replacing :mutex with :recursive_mutex in: static boost::mutex *vmutex = new boost::mutex(); in: contrib/epee/src/mlocker.cpp

The code looks right wrt recursion though.

<woodser> still locks

Another way if you can't get a stack trace is to modify the macro to print the file/line where the calls happens alog with the calling thread, *both* before and after the lock call, and in the object dtor (with thread too).

<woodser> how should I print the calling thread?

<woodser> you mean print the caller before calling it, or is there a way to access the thread info to print?

Print the line number from the macro (__LINE__) in the ctor. For the thread id, you're on your own.

Oh, easylogging.cc will have it, since it uses it and supports emscripten.

Hmm, looks like std::this_thread::get_id(); might work.

<woodser> it hangs on the call to CRITICAL_REGION_LOCAL(mutex()) in get_page_size() which is called from lock()

<woodser> line 109: github.com/monero-project/monero/bl…r/contrib/epee/src/mlocker.cpp#L109

Can you paste the output ?

<woodser> what object constructor should output be printed from?

critical_region_t

__LINE__ should be in the macro itself, not the ctor.

<woodser> paste.debian.net/1120366

The very first call hangs ? WTF.

<woodser> yeah

That points to boost or emscripten being buggy.

Or my code being buggy in a way I've not figured out yet :)

The mutex is returned as a ref to a static. I don't think anything else does that.

<woodser> I’m only building with boost system, thread, and chrono

It returns from the sleep, right ? It's an old debug thing (and is meant to sleep for 0 unless debugging).

<woodser> it doesn’t return from sleep

<woodser> I have a warning: undefined symbol: _ZN5boost24scoped_static_mutex_lockC1ERNS_12static_mutexEb

<woodser> it could be something with my setup

That looks like it should be an error, unless it's doing weak linkage and it gets resolved later. Looks weird to me anyway.

<woodser> emscripten is configured to not fail on undefined symbols

What does it do it undefined ? Leave the ref to point to some random memory ?

<woodser> I’ve seen runtime errors when it hits an undefined symbol

<woodser> with a helpful error message saying something to the effect

<woodser> linking to boost_regex resolved the warning but not the hanging issue. err and errx are the only undefined symbol warnings now

Hmm. These are esoteric libc routines.

<woodser> perhaps multithreading needs to be enabled using pthreads

<woodser> I’ll experiment more with that. it’s part of emscripten’s build process

monero definitely needs multithreading to work.

monero-blockchain-prune running for over 3 hours now on my geekbox. 2GB RAM, microSD cards. def not an ideal setting.

It's probably running lmdb with bad settings, it's been repotred to be pretty slow before.

well, the SDcard appears to be maxed out reading at 15MB/s so that can't e helping

it's just a slow machine

I think this SDcard is a few years old. could probably swap in a newer faster one

seems to me we shouldn't be seeing "LMDB Mapsize increased" in this tool. you know the size of the original blockchain. could just pick a new size that's 40% of that.

anyway that's a minor poitn, not a huge perf impact