11:47:01 <moneromooo> woodser: does this work ? Looks like in the end it's all that ought to be needed for mlock: https://paste.debian.net/hidden/4c51cad5/
13:44:51 <kovri-slack2> <woodser> @moneromooo the patch does not prevent what is commented out in this diff from executing, and so still hangs
13:44:55 <kovri-slack2> <woodser> https://github.com/monero-project/monero/compare/master...woodser:wasm_modifications#diff-c0db3a8a2c8e06418d35f3da238b0b2a
13:47:19 <moneromooo> Get me an all thread stack trace please.
13:47:42 <moneromooo> Hrm. Can you actually do that with js ?
13:48:02 <kovri-slack2> <woodser> that would be really nice but I do not know how to do that from js to webassembly
13:48:06 <kovri-slack2> <woodser> I will research
13:49:55 <moneromooo> I guess we can define out pretty much everything, but if possible I'd prefer to understand where it's hanging.
13:50:14 <moneromooo> mlock is undefined on windows, and that one doesn't hang AFAIK.
13:50:38 <kovri-slack2> <woodser> I recall from building and debugging that CRITICAL_REGION_LOCAL seemed to be the problem point
13:50:54 <moneromooo> Did you change that ?
13:51:00 <kovri-slack2> <woodser> yes
13:51:11 <moneromooo> Did you change anything else ?
13:51:35 <kovri-slack2> <woodser> yes.  all changes to mlocker.cpp are in the diff I linked
13:51:57 <moneromooo> What you linked doesn't include any changes to CRITICAL_REGION_LOCAL.
13:52:21 <moneromooo> So you didn't change it, you just commented out the calls to it ?
13:52:41 <kovri-slack2> <woodser> right
13:53:01 <moneromooo> Plenty of other places in monero use it. Do they hang ?
13:58:47 <kovri-slack2> <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
14:03:07 <moneromooo> Or you can try replacing :mutex with :recursive_mutex in: static boost::mutex *vmutex = new boost::mutex(); in: contrib/epee/src/mlocker.cpp
14:07:09 <moneromooo> The code looks right wrt recursion though.
14:11:20 <kovri-slack2> <woodser> still locks
14:18:14 <moneromooo> 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).
14:20:01 <kovri-slack2> <woodser> how should I print the calling thread?
14:21:01 <kovri-slack2> <woodser> you mean print the caller before calling it, or is there a way to access the thread info to print?
14:29:51 <moneromooo> Print the line number from the macro (__LINE__) in the ctor. For the thread id, you're on your own.
14:30:43 <moneromooo> Oh, easylogging.cc will have it, since it uses it and supports emscripten.
14:31:32 <moneromooo> Hmm, looks like std::this_thread::get_id(); might work.
14:43:49 <kovri-slack2> <woodser> it hangs on the call to CRITICAL_REGION_LOCAL(mutex()) in get_page_size() which is called from lock()
14:44:39 <kovri-slack2> <woodser> line 109: https://github.com/monero-project/monero/blob/master/contrib/epee/src/mlocker.cpp#L109
14:46:38 <moneromooo> Can you paste the  output ?
14:50:51 <kovri-slack2> <woodser> what object constructor should output be printed from?
14:51:53 <moneromooo> critical_region_t
14:52:05 <moneromooo> __LINE__ should be in the macro itself, not the ctor.
15:05:31 <kovri-slack2> <woodser> https://paste.debian.net/1120366/
15:07:32 <moneromooo> The very first call hangs ? WTF.
15:07:59 <kovri-slack2> <woodser> yeah
15:07:59 <moneromooo> That points to boost or emscripten being buggy.
15:08:38 <moneromooo> Or my code being buggy in a way I've not figured out yet :)
15:08:58 <moneromooo> The mutex is returned as a ref to a static. I don't think anything else does that.
15:10:01 <kovri-slack2> <woodser> I’m only building with boost system, thread, and chrono
15:10:17 <moneromooo> It returns from the sleep, right ? It's an old debug thing (and is meant to sleep for 0 unless debugging).
15:10:38 <kovri-slack2> <woodser> it doesn’t return from sleep
15:10:46 <kovri-slack2> <woodser> I have a warning: undefined symbol: _ZN5boost24scoped_static_mutex_lockC1ERNS_12static_mutexEb
15:10:49 <kovri-slack2> <woodser> it could be something with my setup
15:12:08 <moneromooo> That looks like it should be an error, unless it's doing weak linkage and it gets resolved later. Looks weird to me anyway.
15:12:45 <kovri-slack2> <woodser> emscripten is configured to not fail on undefined symbols
15:13:27 <moneromooo> What does it do it undefined ? Leave the ref to point to some random memory ?
15:13:46 <kovri-slack2> <woodser> I’ve seen runtime errors when it hits an undefined symbol
15:14:12 <kovri-slack2> <woodser> with a helpful error message saying something to the effect
16:10:00 <kovri-slack2> <woodser> linking to boost_regex resolved the warning but not the hanging issue.  err and errx are the only undefined symbol warnings now
16:13:19 <moneromooo> Hmm. These are esoteric libc routines.
16:22:14 <kovri-slack2> <woodser> perhaps multithreading needs to be enabled using pthreads
16:24:48 <kovri-slack2> <woodser> I’ll experiment more with that.  it’s part of emscripten’s build process
16:27:58 <moneromooo> monero definitely needs multithreading to work.
20:31:09 <hyc> monero-blockchain-prune running for over 3 hours now on my geekbox. 2GB RAM, microSD cards. def not an ideal setting.
20:33:31 <moneromooo> It's probably running lmdb with bad settings, it's been repotred to be pretty slow before.
20:35:20 <hyc> well, the SDcard appears to be maxed out reading at 15MB/s so that can't e helping
20:35:43 <hyc> it's just a slow machine
20:38:01 <hyc> I think this SDcard is a few years old. could probably swap in a newer faster one
20:43:20 <hyc> 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.
20:51:20 <hyc> anyway that's a minor poitn, not a huge perf impact