This is the trace I have here on GTK, I think EFL is also broken now: Thread 1 (Thread 0x7fee3f3b0a80 (LWP 10421)): #0 0x00007ffc7d4e5a3d in clock_gettime () #1 0x00007fee3217cccd in __GI___clock_gettime (clock_id=<optimized out>, tp=<optimized out>) at ../sysdeps/unix/clock_gettime.c:115 #2 0x00007fee329cff8e in std::chrono::_V2::system_clock::now() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007fee3b7a6acf in WTF::ParkingLot::parkConditionally(void const*, std::function<bool ()>, std::function<void ()>, std::chrono::time_point<std::chrono::_V2::steady_clock, std::chrono::duration<long, std::ratio<1l, 1000000000l> > >) () from /home/phil/wkbuild/lib/libjavascriptcoregtk-4.0.so.18 #4 0x00007fee3b40193d in JSC::GCThreadSharedData::GCThreadSharedData(JSC::VM*) () from /home/phil/wkbuild/lib/libjavascriptcoregtk-4.0.so.18 #5 0x00007fee3b4031d7 in JSC::Heap::Heap(JSC::VM*, JSC::HeapType) () from /home/phil/wkbuild/lib/libjavascriptcoregtk-4.0.so.18 #6 0x00007fee3b73ca1c in JSC::VM::VM(JSC::VM::VMType, JSC::HeapType) () from /home/phil/wkbuild/lib/libjavascriptcoregtk-4.0.so.18 #7 0x00007fee3b73eb74 in JSC::VM::create(JSC::HeapType) () from /home/phil/wkbuild/lib/libjavascriptcoregtk-4.0.so.18 #8 0x00007fee3b73eb89 in JSC::VM::createLeaked(JSC::HeapType) () from /home/phil/wkbuild/lib/libjavascriptcoregtk-4.0.so.18 #9 0x00007fee3d62c19c in WebCore::JSDOMWindowBase::commonVM() () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #10 0x00007fee3d5f7645 in WebCore::mainThreadNormalWorld() () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #11 0x00007fee3d691999 in WebCore::ScriptController::enableEval() () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #12 0x00007fee3db5857a in WebCore::FrameLoader::clear(WebCore::Document*, bool, bool, bool) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #13 0x00007fee3db401f1 in WebCore::DocumentWriter::begin(WebCore::URL const&, bool, WebCore::Document*) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #14 0x00007fee3db33faa in WebCore::DocumentLoader::commitData(char const*, unsigned long) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #15 0x00007fee3d3b65f6 in WebKit::WebFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, char const*, int) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #16 0x00007fee3db365a7 in WebCore::DocumentLoader::commitLoad(char const*, int) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #17 0x00007fee3dbc1fa9 in WebCore::CachedRawResource::notifyClientsDataWasReceived(char const*, unsigned int) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #18 0x00007fee3dbc2099 in WebCore::CachedRawResource::addDataBuffer(WebCore::SharedBuffer&) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #19 0x00007fee3db8ada2 in WebCore::SubresourceLoader::didReceiveDataOrBuffer(char const*, int, WTF::PassRefPtr<WebCore::SharedBuffer>, long long, WebCore::DataPayloadType) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #20 0x00007fee3db8af0b in WebCore::SubresourceLoader::didReceiveData(char const*, unsigned int, long long, WebCore::DataPayloadType) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #21 0x00007fee3d4d1b16 in WebKit::WebResourceLoader::didReceiveWebResourceLoaderMessage(IPC::Connection&, IPC::MessageDecoder&) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #22 0x00007fee3d22853b in IPC::Connection::dispatchMessage(std::unique_ptr<IPC::MessageDecoder, std::default_delete<IPC::MessageDecoder> >) () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #23 0x00007fee3d228fe4 in IPC::Connection::dispatchOneMessage() () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #24 0x00007fee3e90ef2f in WTF::RunLoop::performWork() () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #25 0x00007fee3b7d95d5 in WTF::GMainLoopSource::voidCallback() () from /home/phil/wkbuild/lib/libjavascriptcoregtk-4.0.so.18 #26 0x00007fee3b7d766a in WTF::GMainLoopSource::voidSourceCallback(WTF::GMainLoopSource*) () from /home/phil/wkbuild/lib/libjavascriptcoregtk-4.0.so.18 #27 0x00007fee38b127ed in g_main_dispatch (context=0x16e25b0) at gmain.c:3122 #28 g_main_context_dispatch (context=context@entry=0x16e25b0) at gmain.c:3737 #29 0x00007fee38b12b88 in g_main_context_iterate (context=0x16e25b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808 #30 0x00007fee38b12ea2 in g_main_loop_run (loop=0x1d73ca0) at gmain.c:4002 #31 0x00007fee3e914680 in WTF::RunLoop::run() () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #32 0x00007fee3d4a20e2 in WebProcessMainUnix () from /home/phil/wkbuild/lib/libwebkit2gtk-4.0.so.37 #33 0x00007fee320abb45 in __libc_start_main (main=0x400b30 <main>, argc=2, argv=0x7ffc7d4cf9c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc7d4cf9b8) at libc-start.c:287 #34 0x0000000000400b85 in _start () This is quite an important regression, it prevents any website to load here :(
Hi Filip, we are going to need to roll this out unless you can discover what went wrong, due to the severity of the issue.
can you be clear on how to reproduce?
I'm just trying to load Google with the MiniBrowser. The loading progress bar hangs at some point. Perhaps this is related with the libsoup implementation of the ResourceLoader and then that'd be why it works fine on Mac.
Ok, go ahead and roll it out. I'm afk right now so I can't do it.
*** This bug has been marked as a duplicate of bug 148029 ***
I think I have a fix. By the way, the API tests I added as part of the patch would have instantly caught this - all of the Condition tests timeout all the time. Do the Linux ports run API tests?
(In reply to comment #6) > I think I have a fix. > > By the way, the API tests I added as part of the patch would have instantly > caught this > - all of the Condition tests timeout all the time. > > Do the Linux ports run API tests? Not on the EWS.
This appears to be a bug in libstdc++, as the original patch works fine with libc++. With libstdc++, std::condition_variable defaults to using std::chrono::system_clock and in wait_until() converts a time point originating from any other clock to a value that can be used against any time point originating from std::chrono::system_clock. Pasing in std::chrono::steady_clock::max() results in an overflow, with pthread_cond_timedwait() being called with a timespec object with incorrect values, e.g. {tv_sec = -7783961280, tv_nsec = -919221907}. Because of that pthread_cond_timedwait() (checking that nanoseconds have a meaningful value) immediately returns with EINVAL as the return value, but std::condition_variable::wait_until() disregards the error and returns as if the timeout had not been reached.
This is a known bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931 Also relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
(In reply to comment #9) > This is a known bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931 > Also relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 Thanks for the investigation! Do you want to replace my comment in http://trac.webkit.org/changeset/188499/trunk/Source/WTF/wtf/ParkingLot.cpp with a comment about what you found?
(In reply to comment #10) > (In reply to comment #9) > > This is a known bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931 > > Also relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 > > Thanks for the investigation! > > Do you want to replace my comment in > http://trac.webkit.org/changeset/188499/trunk/Source/WTF/wtf/ParkingLot.cpp > with a comment about what you found? Bug #148571.