Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
The build server still redirects to HTTP after logging in, and when starting the slaves.
Posts: 1,469
Threads: 57
Joined: Jul 2012
Thanks: 66
Given 127 thank(s) in 108 post(s)
I should have fixed the redirect, and I'm in the process of forcing HTTPS and setting up HSTS.
Posts: 1,469
Threads: 57
Joined: Jul 2012
Thanks: 66
Given 127 thank(s) in 108 post(s)
The buildserver now has HSTS, redirects to HTTPS, and has improved security settings.
Posts: 1,469
Threads: 57
Joined: Jul 2012
Thanks: 66
Given 127 thank(s) in 108 post(s)
HSTS is added to all properties I control, and the newsletter has HTTPS also. The only remaining insecure property I control is the DO install server, but that is in need of a proper rewrite anyway.
Now it's time to get all the other sites switched over 
Posts: 513
Threads: 10
Joined: May 2014
Thanks: 138
Given 89 thank(s) in 75 post(s)
I am not sure, but a int value shouldn't get increased by 2 threads without a lock. This happens on start of the server.
The line 98 in SpawnPrepare.cpp is: m_NumPrepared += 1.
Code: ==================
WARNING: ThreadSanitizer: data race (pid=20803)
Write of size 4 at 0x7ffcb7d8d124 by main thread (mutexes: write M129381):
#0 cSpawnPrepare::PreparedChunkCallback(int, int) /home/lukas/cpp/cuberite/src/SpawnPrepare.cpp:98 (Cuberite+0x00000069eeac)
#1 cSpawnPrepareCallback::Call(int, int, bool) /home/lukas/cpp/cuberite/src/SpawnPrepare.cpp:25 (Cuberite+0x00000069f1cf)
#2 cChunkMap::PrepareChunk(int, int, std::unique_ptr<cChunkCoordCallback, std::default_delete<cChunkCoordCallback> >) /home/lukas/cpp/cuberite/src/ChunkMap.cpp:2435 (Cuberite+0x00000060a96a)
#3 cWorld::PrepareChunk(int, int, std::unique_ptr<cChunkCoordCallback, std::default_delete<cChunkCoordCallback> >) /home/lukas/cpp/cuberite/src/World.cpp:3140 (Cuberite+0x0000006d5861)
#4 cSpawnPrepare::PrepareChunks(cWorld&, int, int, int) /home/lukas/cpp/cuberite/src/SpawnPrepare.cpp:63 (Cuberite+0x00000069eceb)
#5 cWorld::InitializeSpawn() /home/lukas/cpp/cuberite/src/World.cpp:354 (Cuberite+0x0000006b9bea)
#6 cRoot::StartWorlds() /home/lukas/cpp/cuberite/src/Root.cpp:418 (Cuberite+0x000000688e69)
#7 UniversalMain(std::unique_ptr<cSettingsRepositoryInterface, std::default_delete<cSettingsRepositoryInterface> >) /home/lukas/cpp/cuberite/src/main.cpp:220 (Cuberite+0x0000006ddd9e)
#8 main /home/lukas/cpp/cuberite/src/main.cpp:534 (Cuberite+0x0000006e2140)
Previous write of size 4 at 0x7ffcb7d8d124 by thread T4:
#0 cSpawnPrepare::PreparedChunkCallback(int, int) /home/lukas/cpp/cuberite/src/SpawnPrepare.cpp:98 (Cuberite+0x00000069eeac)
#1 cSpawnPrepareCallback::Call(int, int, bool) /home/lukas/cpp/cuberite/src/SpawnPrepare.cpp:25 (Cuberite+0x00000069f1cf)
#2 cLightingThread::LightChunk(cLightingThread::cLightingChunkStay&) /home/lukas/cpp/cuberite/src/LightingThread.cpp:327 (Cuberite+0x000000655ecc)
#3 cLightingThread::Execute() /home/lukas/cpp/cuberite/src/LightingThread.cpp:228 (Cuberite+0x0000006558a1)
#4 cIsThread::DoExecute() /home/lukas/cpp/cuberite/src/OSSupport/IsThread.cpp:74 (Cuberite+0x0000006f7d26)
#5 void std::_Mem_fn<void (cIsThread::*)()>::operator()<, void>(cIsThread*) const /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/functional:569 (Cuberite+0x0000006f8505)
#6 std::this_thread::__sleep_for(std::chrono::duration<long, std::ratio<1l, 1l> >, std::chrono::duration<long, std::ratio<1l, 1000000000l> >) <null> (libstdc++.so.6+0x00000008d38f)
Location is stack of main thread.
Mutex M129381 (0x7d3c0000d200) created at:
#0 pthread_mutex_lock <null> (Cuberite+0x0000005900a0)
#1 __gthread_mutex_lock(pthread_mutex_t*) /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/x86_64-linux-gnu/c++/4.9/bits/gthr-default.h:748 (Cuberite+0x0000006f4f6d)
#2 cChunkMap::Tick(std::chrono::duration<long, std::ratio<1l, 1000l> >) /home/lukas/cpp/cuberite/src/ChunkMap.cpp:2792 (Cuberite+0x00000060c05a)
#3 cWorld::Tick(std::chrono::duration<long, std::ratio<1l, 1000l> >, std::chrono::duration<long, std::ratio<1l, 1000l> >) /home/lukas/cpp/cuberite/src/World.cpp:983 (Cuberite+0x0000006b5ad2)
#4 cWorld::cTickThread::Execute() /home/lukas/cpp/cuberite/src/World.cpp:110 (Cuberite+0x0000006b5688)
#5 cIsThread::DoExecute() /home/lukas/cpp/cuberite/src/OSSupport/IsThread.cpp:74 (Cuberite+0x0000006f7d26)
#6 void std::_Mem_fn<void (cIsThread::*)()>::operator()<, void>(cIsThread*) const /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/functional:569 (Cuberite+0x0000006f8505)
#7 std::this_thread::__sleep_for(std::chrono::duration<long, std::ratio<1l, 1l> >, std::chrono::duration<long, std::ratio<1l, 1000000000l> >) <null> (libstdc++.so.6+0x00000008d38f)
Thread T4 (tid=20808, running) created by main thread at:
#0 pthread_create <null> (Cuberite+0x000000571251)
#1 std::thread::_M_start_thread(std::shared_ptr<std::thread::_Impl_base>, void (*)()) <null> (libstdc++.so.6+0x00000008d4d2)
#2 cIsThread::Start() /home/lukas/cpp/cuberite/src/OSSupport/IsThread.cpp:86 (Cuberite+0x0000006f7d93)
#3 cLightingThread::Start(cWorld*) /home/lukas/cpp/cuberite/src/LightingThread.cpp:118 (Cuberite+0x0000006553fe)
#4 cWorld::Start() /home/lukas/cpp/cuberite/src/World.cpp:550 (Cuberite+0x0000006bda5d)
#5 cRoot::StartWorlds() /home/lukas/cpp/cuberite/src/Root.cpp:417 (Cuberite+0x000000688e58)
#6 UniversalMain(std::unique_ptr<cSettingsRepositoryInterface, std::default_delete<cSettingsRepositoryInterface> >) /home/lukas/cpp/cuberite/src/main.cpp:220 (Cuberite+0x0000006ddd9e)
#7 main /home/lukas/cpp/cuberite/src/main.cpp:534 (Cuberite+0x0000006e2140)
SUMMARY: ThreadSanitizer: data race /home/lukas/cpp/cuberite/src/SpawnPrepare.cpp:98 cSpawnPrepare::PreparedChunkCallback(int, int)
Posts: 513
Threads: 10
Joined: May 2014
Thanks: 138
Given 89 thank(s) in 75 post(s)
12-20-2015, 07:48 AM
(This post was last modified: 12-20-2015, 07:49 AM by Seadragon91.)
Could this above be the cause for a rare deadlock, that happens at startup in spawn generation?
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
Possibly, but I'd expect this to be pretty rare, as it would require a chunk to load, and another to finish lighting in the same cycle on a multicore machine, or a timer interrupt to occur in exactly one cycle. I've submitted a fix.
Posts: 513
Threads: 10
Joined: May 2014
Thanks: 138
Given 89 thank(s) in 75 post(s)
We had around 5 (or more) pull requests who deadlocked. On my computer I had 3 of them 
Posts: 783
Threads: 12
Joined: Jan 2014
Thanks: 2
Given 73 thank(s) in 61 post(s)
Thats why I don't think its this. Also the PR's where failing because they couldn't find a valid spawn, not that they couldn't load it.
Posts: 513
Threads: 10
Joined: May 2014
Thanks: 138
Given 89 thank(s) in 75 post(s)
Ops, you are right. Something is also not correct, it looks like the code in the condition if (CanSpawnAt(...) is unreachable. I always get the message "Did not find an acceptable spawnpoint"
|
