Bug 146729

Summary: Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) in IPC::Connection::sendOutgoingMessage
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: WebKit2Assignee: Michael Catanzaro <mcatanzaro>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, cgarcia, mcatanzaro, mcrha, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
See Also: https://bugs.webkit.org/show_bug.cgi?id=220668
Bug Depends on:    
Bug Blocks: 204997    
Attachments:
Description Flags
debug patch
none
Patch
none
Patch
none
Patch none

Michael Catanzaro
Reported 2015-07-08 09:37:00 PDT
I see some bad complaints from valgrind when starting Epiphany: ==18581== Thread 11: ==18581== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) ==18581== at 0xCA98A9D: ??? (syscall-template.S:81) ==18581== by 0x68D50FB: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >) (ConnectionUnix.cpp:525) ==18581== by 0x673FA2E: IPC::Connection::sendOutgoingMessages() (Connection.cpp:786) ==18581== by 0x8AB9E14: UnknownInlinedFun (functional:2271) ==18581== by 0x8AB9E14: WTF::GMainLoopSource::voidCallback() (GMainLoopSource.cpp:365) ==18581== by 0x8AB6019: WTF::GMainLoopSource::voidSourceCallback(WTF::GMainLoopSource*) (GMainLoopSource.cpp:456) ==18581== by 0xBF09A89: g_main_dispatch (gmain.c:3122) ==18581== by 0xBF09A89: g_main_context_dispatch (gmain.c:3737) ==18581== by 0xBF09E1F: g_main_context_iterate.isra.29 (gmain.c:3808) ==18581== by 0xBF0A141: g_main_loop_run (gmain.c:4002) ==18581== by 0x8A95F24: operator() (functional:2271) ==18581== by 0x8A95F24: WTF::threadEntryPoint(void*) (Threading.cpp:58) ==18581== by 0x8AB2C79: WTF::wtfThreadEntryPoint(void*) (ThreadingPthreads.cpp:170) ==18581== by 0xCA90554: start_thread (pthread_create.c:333) ==18581== by 0xCDA6F3C: clone (clone.S:109) ==18581== Address 0x2def28e1 is on thread 11's stack ==18581== in frame #1, created by IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >) (ConnectionUnix.cpp:422) ==18581== ==18581== Thread 12: ==18581== Syscall param sendmsg(msg.msg_iov[1]) points to uninitialised byte(s) ==18581== at 0xCA98A9D: ??? (syscall-template.S:81) ==18581== by 0x68D50FB: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >) (ConnectionUnix.cpp:525) ==18581== by 0x673FA2E: IPC::Connection::sendOutgoingMessages() (Connection.cpp:786) ==18581== by 0x8AB9E14: UnknownInlinedFun (functional:2271) ==18581== by 0x8AB9E14: WTF::GMainLoopSource::voidCallback() (GMainLoopSource.cpp:365) ==18581== by 0x8AB6019: WTF::GMainLoopSource::voidSourceCallback(WTF::GMainLoopSource*) (GMainLoopSource.cpp:456) ==18581== by 0xBF09A89: g_main_dispatch (gmain.c:3122) ==18581== by 0xBF09A89: g_main_context_dispatch (gmain.c:3737) ==18581== by 0xBF09E1F: g_main_context_iterate.isra.29 (gmain.c:3808) ==18581== by 0xBF0A141: g_main_loop_run (gmain.c:4002) ==18581== by 0x8A95F24: operator() (functional:2271) ==18581== by 0x8A95F24: WTF::threadEntryPoint(void*) (Threading.cpp:58) ==18581== by 0x8AB2C79: WTF::wtfThreadEntryPoint(void*) (ThreadingPthreads.cpp:170) ==18581== by 0xCA90554: start_thread (pthread_create.c:333) ==18581== by 0xCDA6F3C: clone (clone.S:109) ==18581== Address 0x2601ac54 is not stack'd, malloc'd or (recently) free'd
Attachments
debug patch (947 bytes, text/plain)
2020-03-19 04:53 PDT, Milan Crha
no flags
Patch (1.62 KB, patch)
2020-03-22 08:18 PDT, Michael Catanzaro
no flags
Patch (1.67 KB, patch)
2020-03-23 11:43 PDT, Michael Catanzaro
no flags
Patch (1.79 KB, patch)
2020-03-23 11:46 PDT, Michael Catanzaro
no flags
Michael Catanzaro
Comment 1 2015-07-08 09:37:20 PDT
This is with 2.8.3.
Michael Catanzaro
Comment 2 2016-03-11 11:10:54 PST
Possibly related to bug #153637?
Michael Catanzaro
Comment 3 2016-07-30 16:00:17 PDT
Ran it with --track-origins=yes, looks like two different bugs maybe: ==722== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) ==722== at 0x17B7B2FD: ??? (in /usr/lib64/libpthread-2.23.so) ==722== by 0xAD90515: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >) (ConnectionUnix.cpp:508) ==722== by 0xA8DB34B: IPC::Connection::sendOutgoingMessages() (Connection.cpp:811) ==722== by 0xA8D862D: IPC::Connection::sendMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >, unsigned int, bool)::{lambda()#1}::operator()() (Connection.cpp:378) ==722== by 0xA8E094B: WTF::Function<void ()>::CallableWrapper<IPC::Connection::sendMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >, unsigned int, bool)::{lambda()#1}>::call() (Function.h:89) ==722== by 0xA8AABF6: WTF::Function<void ()>::operator()() const (Function.h:50) ==722== by 0x12C62243: WTF::WorkQueue::dispatch(WTF::Function<void ()>&&)::{lambda()#1}::operator()() const (WorkQueueGeneric.cpp:88) ==722== by 0x12C6364F: WTF::Function<void ()>::CallableWrapper<WTF::WorkQueue::dispatch(WTF::Function<void ()>&&)::{lambda()#1}>::call() (Function.h:89) ==722== by 0xA8AABF6: WTF::Function<void ()>::operator()() const (Function.h:50) ==722== by 0x12C29A2D: WTF::RunLoop::performWork() (RunLoop.cpp:122) ==722== by 0x12C64635: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:66) ==722== by 0x12C64659: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:68) ==722== Address 0x347ff5d1 is on thread 9's stack ==722== in frame #1, created by IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >) (ConnectionUnix.cpp:408) ==722== Uninitialised value was created by a stack allocation ==722== at 0xAD8FD5C: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >) (ConnectionUnix.cpp:408) ==722== ==722== Syscall param sendmsg(msg.msg_iov[1]) points to uninitialised byte(s) ==722== at 0x17B7B2FD: ??? (in /usr/lib64/libpthread-2.23.so) ==722== by 0xAD90515: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >) (ConnectionUnix.cpp:508) ==722== by 0xA8DB34B: IPC::Connection::sendOutgoingMessages() (Connection.cpp:811) ==722== by 0xA8D862D: IPC::Connection::sendMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >, unsigned int, bool)::{lambda()#1}::operator()() (Connection.cpp:378) ==722== by 0xA8E094B: WTF::Function<void ()>::CallableWrapper<IPC::Connection::sendMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >, unsigned int, bool)::{lambda()#1}>::call() (Function.h:89) ==722== by 0xA8AABF6: WTF::Function<void ()>::operator()() const (Function.h:50) ==722== by 0x12C62243: WTF::WorkQueue::dispatch(WTF::Function<void ()>&&)::{lambda()#1}::operator()() const (WorkQueueGeneric.cpp:88) ==722== by 0x12C6364F: WTF::Function<void ()>::CallableWrapper<WTF::WorkQueue::dispatch(WTF::Function<void ()>&&)::{lambda()#1}>::call() (Function.h:89) ==722== by 0xA8AABF6: WTF::Function<void ()>::operator()() const (Function.h:50) ==722== by 0x12C29A2D: WTF::RunLoop::performWork() (RunLoop.cpp:122) ==722== by 0x12C64635: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:66) ==722== by 0x12C64659: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:68) ==722== Address 0x273e109d is in a rw- anonymous segment ==722== Uninitialised value was created by a stack allocation ==722== at 0xAA50943: WebKit::WebProcessPool::ensureNetworkProcess() (WebProcessPool.cpp:338)
Michael Catanzaro
Comment 4 2016-07-30 19:42:26 PDT
Here's a third one, I guess it occurs when loading the overview: ==9639== Syscall param sendmsg(msg.msg_iov[1]) points to uninitialised byte(s) ==9639== at 0x17CAF2FD: ??? (in /usr/lib64/libpthread-2.23.so) ==9639== by 0xADE549D: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >) (ConnectionUnix.cpp:506) ==9639== by 0xA925B01: IPC::Connection::sendOutgoingMessages() (Connection.cpp:820) ==9639== by 0xA922D67: IPC::Connection::sendMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >, unsigned int, bool)::{lambda()#1}::operator()() (Connection.cpp:378) ==9639== by 0xA92B101: WTF::Function<void ()>::CallableWrapper<IPC::Connection::sendMessage(std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >, unsigned int, bool)::{lambda()#1}>::call() (Function.h:101) ==9639== by 0xA8F5E3A: WTF::Function<void ()>::operator()() const (Function.h:50) ==9639== by 0x12D713EB: WTF::WorkQueue::dispatch(WTF::Function<void ()>&&)::{lambda()#1}::operator()() const (WorkQueueGeneric.cpp:88) ==9639== by 0x12D727F7: WTF::Function<void ()>::CallableWrapper<WTF::WorkQueue::dispatch(WTF::Function<void ()>&&)::{lambda()#1}>::call() (Function.h:101) ==9639== by 0xA8F5E3A: WTF::Function<void ()>::operator()() const (Function.h:50) ==9639== by 0x12D30C03: WTF::RunLoop::performWork() (RunLoop.cpp:122) ==9639== by 0x12D737DD: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::operator()(void*) const (RunLoopGLib.cpp:66) ==9639== by 0x12D73801: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:68) ==9639== Address 0x359d5e00 is in a rw- anonymous segment ==9639== Uninitialised value was created by a stack allocation ==9639== at 0xAA3E093: WebKit::WebPageProxy::loadAlternateHTMLString(WTF::String const&, WTF::String const&, WTF::String const&, API::Object*) (WebPageProxy.cpp:1051)
Michael Catanzaro
Comment 5 2016-07-30 21:28:09 PDT
So: In WebPageProxy::loadAlternateHTMLString we never initialize the request, sandboxExtensionHandle, data, MIMEType, or encodingName properties of LoadParameters. It's arguably not a bug if we never use those parameters, but valgrind justifiably complains that we pass uninitialized memory into the kernel. Let's avoid it by zero-initializing the struct. In the case of WebProcessPool::ensureNetworkProcess, there's a bunch of stuff we're not initializing in NetworkProcessCreationParameters (e.g. the sandbox extension handles are only conditionally-initialized). Again, we ought to zero-initialize the struct. The one that valgrind says originates in IPC::Connection::sendOutgoingMessage is less obvious, still trying to figure it out.
Milan Crha
Comment 6 2016-09-07 01:06:14 PDT
The 2.13.90 gives me these: ==17692== Warning: set address range perms: large range [0x395d9000, 0x795db000) (noaccess) ==17692== Thread 4: ==17692== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) ==17692== at 0x772166D: ??? (in /usr/lib64/libc-2.23.so) ==17692== by 0x559B881: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x535316B: IPC::Connection::sendOutgoingMessages() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0xA8F780A: WTF::RunLoop::performWork() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92C258: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x977E802: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EBAF: ??? (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EED1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0xA92CB3F: WTF::RunLoop::run() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92B867: std::_Function_handler<void (), WTF::WorkQueue::platformInitialize(char const*, WTF::WorkQueue::Type, WTF::WorkQueue::QOS)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA8F86E7: WTF::threadEntryPoint(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA929CAC: WTF::wtfThreadEntryPoint(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xB19F589: start_thread (in /usr/lib64/libpthread-2.23.so) ==17692== by 0x77205CC: clone (in /usr/lib64/libc-2.23.so) ==17692== Address 0x23ba8871 is on thread 4's stack ==17692== in frame #1, created by IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (???:) ==17692== ==17692== Syscall param sendmsg(msg.msg_iov[1]) points to uninitialised byte(s) ==17692== at 0x772166D: ??? (in /usr/lib64/libc-2.23.so) ==17692== by 0x559B881: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x535316B: IPC::Connection::sendOutgoingMessages() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0xA8F780A: WTF::RunLoop::performWork() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92C258: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x977E802: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EBAF: ??? (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EED1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0xA92CB3F: WTF::RunLoop::run() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92B867: std::_Function_handler<void (), WTF::WorkQueue::platformInitialize(char const*, WTF::WorkQueue::Type, WTF::WorkQueue::QOS)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA8F86E7: WTF::threadEntryPoint(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA929CAC: WTF::wtfThreadEntryPoint(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xB19F589: start_thread (in /usr/lib64/libpthread-2.23.so) ==17692== by 0x77205CC: clone (in /usr/lib64/libc-2.23.so) ==17692== Address 0x1b3d3ab9 is 41 bytes inside a block of size 600 alloc'd ==17692== at 0x4C2BBAD: malloc (vg_replace_malloc.c:299) ==17692== by 0xA8EB868: WTF::fastMalloc(unsigned long) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x535254B: IPC::Connection::createSyncMessageEncoder(IPC::StringReference, IPC::StringReference, unsigned long, unsigned long&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5484622: WebKit::WebProcess::ensureNetworkProcessConnection() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x54875A8: WebKit::WebProcess::initializeWebProcess(WebKit::WebProcessCreationParameters&&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5673259: void IPC::handleMessage<Messages::WebProcess::InitializeWebProcess, WebKit::WebProcess, void (WebKit::WebProcess::*)(WebKit::WebProcessCreationParameters&&)>(IPC::Decoder&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(WebKit::WebProcessCreationParameters&&)) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5672033: WebKit::WebProcess::didReceiveWebProcessMessage(IPC::Connection&, IPC::Decoder&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5355595: IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5356547: IPC::Connection::dispatchOneMessage() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0xA8F780A: WTF::RunLoop::performWork() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92C258: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x977E802: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EBAF: ??? (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EED1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0xA92CB3F: WTF::RunLoop::run() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x5620541: int WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x7635720: (below main) (in /usr/lib64/libc-2.23.so) ==17692== ==17692== Thread 1: ==17692== Conditional jump or move depends on uninitialised value(s) ==17692== at 0x552F05E: WebKit::WebPage::setPageActivityState(unsigned int) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5EDBE21: WebCore::Page::setPageActivityState(unsigned int) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5EEAE41: WebCore::PageThrottler::pageLoadActivityCounterChanged() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5EEACCD: WebCore::PageThrottler::pageLoadActivityToken() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5DB5A39: WebCore::FrameLoader::started() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5DB5BC2: WebCore::FrameLoader::didOpenURL() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5DBF57F: WebCore::FrameLoader::commitProvisionalLoad() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5DA4215: WebCore::DocumentLoader::finishedLoading(double) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5DA4B17: WebCore::DocumentLoader::maybeLoadEmpty() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5DA4EA2: WebCore::DocumentLoader::startLoadingMainResource() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5DB8DDA: WebCore::FrameLoader::init() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x551FDE2: WebKit::WebFrame::createWithCoreMainFrame(WebKit::WebPage*, WebCore::Frame*) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x553E08B: WebKit::WebPage::WebPage(unsigned long, WebKit::WebPageCreationParameters const&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x553E66D: WebKit::WebPage::create(unsigned long, WebKit::WebPageCreationParameters const&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5487B07: WebKit::WebProcess::createWebPage(unsigned long, WebKit::WebPageCreationParameters const&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5673C35: void IPC::handleMessage<Messages::WebProcess::CreateWebPage, WebKit::WebProcess, void (WebKit::WebProcess::*)(unsigned long, WebKit::WebPageCreationParameters const&)>(IPC::Decoder&, WebKit::WebProcess*, void (WebKit::WebProcess::*)(unsigned long, WebKit::WebPageCreationParameters const&)) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x56720B3: WebKit::WebProcess::didReceiveWebProcessMessage(IPC::Connection&, IPC::Decoder&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5355595: IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5356547: IPC::Connection::dispatchOneMessage() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0xA8F78D2: WTF::RunLoop::performWork() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92C258: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x977E802: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EBAF: ??? (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EED1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0xA92CB3F: WTF::RunLoop::run() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x5620541: int WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x7635720: (below main) (in /usr/lib64/libc-2.23.so) ==17692== ==17692== Thread 4: ==17692== Syscall param sendmsg(msg.msg_iov[2]) points to uninitialised byte(s) ==17692== at 0x772166D: ??? (in /usr/lib64/libc-2.23.so) ==17692== by 0x559B881: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x535316B: IPC::Connection::sendOutgoingMessages() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0xA8F780A: WTF::RunLoop::performWork() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92C258: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x977E802: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EBAF: ??? (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EED1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0xA92CB3F: WTF::RunLoop::run() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92B867: std::_Function_handler<void (), WTF::WorkQueue::platformInitialize(char const*, WTF::WorkQueue::Type, WTF::WorkQueue::QOS)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA8F86E7: WTF::threadEntryPoint(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA929CAC: WTF::wtfThreadEntryPoint(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xB19F589: start_thread (in /usr/lib64/libpthread-2.23.so) ==17692== by 0x77205CC: clone (in /usr/lib64/libc-2.23.so) ==17692== Address 0x32e2c309 is 41 bytes inside a block of size 600 alloc'd ==17692== at 0x4C2BBAD: malloc (vg_replace_malloc.c:299) ==17692== by 0xA8EB868: WTF::fastMalloc(unsigned long) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x5617D1F: WebKit::AcceleratedDrawingArea::sendDidUpdateBackingStoreState() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x561A298: WebKit::DrawingAreaImpl::sendDidUpdateBackingStoreState() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x561825B: WebKit::AcceleratedDrawingArea::updateBackingStoreState(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x561AEEA: WebKit::DrawingAreaImpl::updateBackingStoreState(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5683491: void IPC::handleMessage<Messages::DrawingArea::UpdateBackingStoreState, WebKit::DrawingArea, void (WebKit::DrawingArea::*)(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&)>(IPC::Decoder&, WebKit::DrawingArea*, void (WebKit::DrawingArea::*)(unsigned long, bool, float, WebCore::IntSize const&, WebCore::IntSize const&)) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x56833A1: WebKit::DrawingArea::didReceiveMessage(IPC::Connection&, IPC::Decoder&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x535965B: IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x548ACA5: WebKit::WebProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5355595: IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x5356547: IPC::Connection::dispatchOneMessage() (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0xA8F78D2: WTF::RunLoop::performWork() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0xA92C258: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x977E802: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EBAF: ??? (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0x977EED1: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.4800.0) ==17692== by 0xA92CB3F: WTF::RunLoop::run() (in /build/local/lib/libjavascriptcoregtk-4.0.so.18.4.4) ==17692== by 0x5620541: int WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) (in /build/local/lib/libwebkit2gtk-4.0.so.37.14.4) ==17692== by 0x7635720: (below main) (in /usr/lib64/libc-2.23.so)
Michael Catanzaro
Comment 7 2016-09-07 05:28:34 PDT
The one in WebKit::AcceleratedDrawingArea::sendDidUpdateBackingStoreState looks like a recent regression
Michael Catanzaro
Comment 8 2020-03-18 18:09:13 PDT
Let's try to fix this one *before* we hit the five-year mark... it is fast approaching! Modern version looks like this: ==449866== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) ==449866== at 0x57FDBED: __libc_sendmsg (sendmsg.c:28) ==449866== by 0x57FDBED: sendmsg (sendmsg.c:25) ==449866== by 0x6806CEC: IPC::Connection::sendOutputMessage(IPC::UnixMessage&) (ConnectionUnix.cpp:486) ==449866== by 0x68075CC: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (ConnectionUnix.cpp:404) ==449866== by 0x67F1ECD: sendOutgoingMessages (Connection.cpp:899) ==449866== by 0x67F1ECD: IPC::Connection::sendOutgoingMessages() (Connection.cpp:884) ==449866== by 0xA521B88: operator() (Function.h:84) ==449866== by 0xA521B88: WTF::RunLoop::performWork() (RunLoop.cpp:119) ==449866== by 0xA56CCF8: operator() (RunLoopGLib.cpp:68) ==449866== by 0xA56CCF8: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (RunLoopGLib.cpp:70) ==449866== by 0x545851F: g_main_dispatch (gmain.c:3216) ==449866== by 0x545851F: g_main_context_dispatch (gmain.c:3881) ==449866== by 0x54588AF: g_main_context_iterate.isra.0 (gmain.c:3954) ==449866== by 0x5458BA2: g_main_loop_run (gmain.c:4148) ==449866== by 0xA56D71F: WTF::RunLoop::run() (RunLoopGLib.cpp:96) ==449866== by 0xA522FA3: operator() (Function.h:84) ==449866== by 0xA522FA3: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (Threading.cpp:168) ==449866== by 0xA56EAF8: WTF::wtfThreadEntryPoint(void*) (ThreadingPOSIX.cpp:200) ==449866== Address 0x41ed8731 is on thread 53's stack ==449866== in frame #2, created by IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (ConnectionUnix.cpp:378) ==449866== Uninitialised value was created by a stack allocation ==449866== at 0x6807550: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (ConnectionUnix.cpp:378)
Michael Catanzaro
Comment 9 2020-03-18 18:20:16 PDT
(In reply to Michael Catanzaro from comment #5) > The one that valgrind says originates in > IPC::Connection::sendOutgoingMessage is less obvious, still trying to figure > it out. Guess: a message attachment contains uninitalized memory? The uninitialized memory must be coming from the UnixMessage, and therefore ultimately from the encoder that gets passed to sendOutgoingMessage. If it were a problem with encoder.buffer() then it would be a heap issue rather than a stack issue, so my guess is the message attachment. Now the problem is going to be tracking it down to a particular message. Not sure how we can do that.
Milan Crha
Comment 10 2020-03-19 04:53:40 PDT
Created attachment 393967 [details] debug patch It seems to be the very first message. I added this debug patch and valgrind claims on the printf() for four times. Maybe some structure padding involved here? The msg_iov[0] is just: iov[0].iov_base = reinterpret_cast<void*>(&messageInfo); iov[0].iov_len = sizeof(messageInfo); If I recall correctly, valgrind can remember issues and only add to the counter, not claiming about them again and again, thus it's possible it's every message, but valgrind doesn't claim, because it already reported the issue.
Michael Catanzaro
Comment 11 2020-03-22 08:04:50 PDT
(In reply to Milan Crha from comment #10) > Maybe some structure padding involved here? Good job Milan, you got it right! I spent several hours trying to figure out what was wrong here... it was indeed uninitialized struct padding. Normally that's fine because struct padding should never be accessed in normal code, but because we're copying the entire MessageInfo into write(), we write() the whole thing. I think there's no correctness problem here, because the uninitialized bytes should only be used for struct padding when read() into the receiving process. But we should pack this class anyway to avoid complaints from valgrind. P.S. packing this struct will result in worse code generation on platforms that disallow unaligned access, but it's surely the right thing to do. P.S.S. There is another solution: heap allocate the MessageInfo instead of stack allocating it. I'm not sure *why* that fixes the warning, but it does. I opted for packing the struct because I didn't understand why.
Michael Catanzaro
Comment 12 2020-03-22 08:18:47 PDT
Milan Crha
Comment 13 2020-03-23 03:04:43 PDT
(In reply to Michael Catanzaro from comment #11) > But we should pack this class anyway to avoid complaints from valgrind. What about: memset(&msg, 0, sizeof (UnixMessage)); would that work? I do not say it's the best solution (one may argue it's no solution at all), but it can work with uninitialized variables/structure members. Does the heap allocation do anything similar?
Michael Catanzaro
Comment 14 2020-03-23 11:13:10 PDT
No, I tried that but it didn't work because it's not a trivially-destructible type. (That clobbers the Vector data member.) I think it might work for the MessageInfo, though. Let me try that.
Michael Catanzaro
Comment 15 2020-03-23 11:41:27 PDT
Yeah it works. That's better. Thanks, Milan!
Michael Catanzaro
Comment 16 2020-03-23 11:43:55 PDT
Michael Catanzaro
Comment 17 2020-03-23 11:46:02 PDT
Milan Crha
Comment 18 2020-03-24 00:11:02 PDT
(In reply to Michael Catanzaro from comment #14) > No, I tried that but it didn't work because it's not a > trivially-destructible type. (That clobbers the Vector data member.) I see. Setting structure content to 0 on classes, not bare structures, feels dangerous. But maybe only because I do not have enough knowledge of how those are treated by the compiler (I'm thinking of virtual and non-virtual functions and the like, not only variables/properties).
Milan Crha
Comment 19 2020-03-24 00:57:30 PDT
The patch works for msg_iov[0], but not for msg_iov[1]. At least here. I'll try a new build. (No debug symbols below, I'm sorry.) ==19209== Thread 13 ReceiveQueue: ==19209== Syscall param sendmsg(msg.msg_iov[1]) points to uninitialised byte(s) ==19209== at 0x105D42B7D: sendmsg (in /usr/lib64/libpthread-2.29.so) ==19209== by 0x1010EA06C: IPC::Connection::sendOutputMessage(IPC::UnixMessage&) (in /build/test-wk2/lib/libwebkit2gtk-4.0.so.37.45.0) ==19209== by 0x1010EA950: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (in /build/test-wk2/lib/libwebkit2gtk-4.0.so.37.45.0) ==19209== by 0x1010D588D: IPC::Connection::sendOutgoingMessages() (in /build/test-wk2/lib/libwebkit2gtk-4.0.so.37.45.0) ==19209== by 0x1058068A8: WTF::RunLoop::performWork() (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105851DE8: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105C4D139: g_main_dispatch (gmain.c:3202) ==19209== by 0x105C4E02F: g_main_context_dispatch (gmain.c:3867) ==19209== by 0x105C4E214: g_main_context_iterate (gmain.c:3940) ==19209== by 0x105C4E63B: g_main_loop_run (gmain.c:4136) ==19209== by 0x10585280F: WTF::RunLoop::run() (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105807CC3: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105853BE8: WTF::wtfThreadEntryPoint(void*) (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105D385A1: start_thread (in /usr/lib64/libpthread-2.29.so) ==19209== by 0x105E4C302: clone (in /usr/lib64/libc-2.29.so) ==19209== Address 0x10a1a33e5 is 5 bytes inside a block of size 256 alloc'd ==19209== at 0x10083880B: malloc (vg_replace_malloc.c:309) ==19209== by 0x1057F73C8: WTF::fastMalloc(unsigned long) (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x1010EAFD0: WTF::Vector<IPC::AttachmentInfo, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>::expandCapacity(unsigned long) (in /build/test-wk2/lib/libwebkit2gtk-4.0.so.37.45.0) ==19209== by 0x1010E9F10: IPC::Connection::sendOutputMessage(IPC::UnixMessage&) (in /build/test-wk2/lib/libwebkit2gtk-4.0.so.37.45.0) ==19209== by 0x1010EA950: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (in /build/test-wk2/lib/libwebkit2gtk-4.0.so.37.45.0) ==19209== by 0x1010D588D: IPC::Connection::sendOutgoingMessages() (in /build/test-wk2/lib/libwebkit2gtk-4.0.so.37.45.0) ==19209== by 0x1058068A8: WTF::RunLoop::performWork() (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105851DE8: WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105C4D139: g_main_dispatch (gmain.c:3202) ==19209== by 0x105C4E02F: g_main_context_dispatch (gmain.c:3867) ==19209== by 0x105C4E214: g_main_context_iterate (gmain.c:3940) ==19209== by 0x105C4E63B: g_main_loop_run (gmain.c:4136) ==19209== by 0x10585280F: WTF::RunLoop::run() (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105807CC3: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105853BE8: WTF::wtfThreadEntryPoint(void*) (in /build/test-wk2/lib/libjavascriptcoregtk-4.0.so.18.17.0) ==19209== by 0x105D385A1: start_thread (in /usr/lib64/libpthread-2.29.so) ==19209== by 0x105E4C302: clone (in /usr/lib64/libc-2.29.so)
Milan Crha
Comment 20 2020-03-24 02:26:45 PDT
Compiled with debug symbols, I get this at r258908 plus the above patch applied when running the MiniBrowser: ==16894== Syscall param sendmsg(msg.msg_iov[1]) points to uninitialised byte(s) ==16894== at 0x105A07B7D: sendmsg (in /usr/lib64/libpthread-2.29.so) ==16894== by 0x10108CA30: IPC::Connection::sendOutputMessage(IPC::UnixMessage&) (ConnectionUnix.cpp:486) ==16894== by 0x10108C1BE: IPC::Connection::sendOutgoingMessage(std::unique_ptr<IPC::Encoder, std::default_delete<IPC::Encoder> >) (ConnectionUnix.cpp:404) ==16894== by 0x10107B1C6: IPC::Connection::sendOutgoingMessages() (Connection.cpp:899) ==16894== by 0x105650358: operator() (Lock.h:84) ==16894== by 0x105650358: WTF::RunLoop::performWork() (RunLoop.cpp:119) ==16894== by 0x10569FA15: operator() (RunLoopGLib.cpp:68) ==16894== by 0x10569FA15: WTF::RunLoop::RunLoop()::$_0::__invoke(void*) (RunLoopGLib.cpp:67) ==16894== by 0x10413A139: g_main_dispatch (gmain.c:3202) ==16894== by 0x10413B02F: g_main_context_dispatch (gmain.c:3867) ==16894== by 0x10413B214: g_main_context_iterate (gmain.c:3940) ==16894== by 0x10413B63B: g_main_loop_run (gmain.c:4136) ==16894== by 0x10569F523: WTF::RunLoop::run() (RunLoopGLib.cpp:96) ==16894== by 0x105651C67: operator() (Function.h:84) ==16894== by 0x105651C67: WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) (Threading.cpp:168) ==16894== by 0x1056A0F85: WTF::wtfThreadEntryPoint(void*) (ThreadingPOSIX.cpp:200) ==16894== by 0x1059FD5A1: start_thread (in /usr/lib64/libpthread-2.29.so) ==16894== by 0x105B13302: clone (in /usr/lib64/libc-2.29.so) ==16894== Address 0x155dae7a8 is 312 bytes inside a block of size 600 alloc'd ==16894== at 0x10083880B: malloc (vg_replace_malloc.c:309) ==16894== by 0x105642525: WTF::fastMalloc(unsigned long) (FastMalloc.cpp:201) ==16894== by 0x101177331: operator new (Encoder.h:40) ==16894== by 0x101177331: make_unique<IPC::Encoder, IPC::StringReference, IPC::StringReference, unsigned long &> (unique_ptr.h:849) ==16894== by 0x101177331: makeUnique<IPC::Encoder, IPC::StringReference, IPC::StringReference, unsigned long &> (StdLibExtras.h:483) ==16894== by 0x101177331: bool WebKit::AuxiliaryProcessProxy::send<Messages::WebPage::LoadRequest>(Messages::WebPage::LoadRequest&&, unsigned long, WTF::OptionSet<IPC::SendOption>) (AuxiliaryProcessProxy.h:153) ==16894== by 0x101115B6A: send<Messages::WebPage::LoadRequest, WebCore::PageIdentifierType> (AuxiliaryProcessProxy.h:58) ==16894== by 0x101115B6A: WebKit::WebPageProxy::loadRequestWithNavigationShared(WTF::Ref<WebKit::WebProcessProxy, WTF::DumbPtrTraits<WebKit::WebProcessProxy> >&&, WTF::ObjectIdentifier<WebCore::PageIdentifierType>, API::Navigation&, WebCore::ResourceRequest&&, WebCore::ShouldOpenExternalURLsPolicy, API::Object*, WebCore::ShouldTreatAsContinuingLoad, WebKit::NavigatingToAppBoundDomain, WebKit::NavigatedAwayFromAppBoundDomain, WTF::Optional<WebKit::WebsitePoliciesData>&&) (WebPageProxy.cpp:1329) ==16894== by 0x10111565B: WebKit::WebPageProxy::loadRequest(WebCore::ResourceRequest&&, WebCore::ShouldOpenExternalURLsPolicy, API::Object*) (WebPageProxy.cpp:1289) ==16894== by 0x1011F0E5D: webkit_web_view_load_uri (WebKitWebView.cpp:2929) ==16894== by 0x416575: main (main.c:639) ==16894== Uninitialised value was created by a heap allocation ==16894== at 0x10083880B: malloc (vg_replace_malloc.c:309) ==16894== by 0x105642525: WTF::fastMalloc(unsigned long) (FastMalloc.cpp:201) ==16894== by 0x10110A3B2: operator new (ThreadSafeRefCounted.h:43) ==16894== by 0x10110A3B2: create (APINavigation.h:85) ==16894== by 0x10110A3B2: WebKit::WebNavigationState::createLoadRequestNavigation(WebCore::ResourceRequest&&, WebKit::WebBackForwardListItem*) (WebNavigationState.cpp:46) ==16894== by 0x101115600: WebKit::WebPageProxy::loadRequest(WebCore::ResourceRequest&&, WebCore::ShouldOpenExternalURLsPolicy, API::Object*) (WebPageProxy.cpp:1284) ==16894== by 0x1011F0E5D: webkit_web_view_load_uri (WebKitWebView.cpp:2929) ==16894== by 0x416575: main (main.c:639)
Michael Catanzaro
Comment 21 2020-03-24 11:54:53 PDT
Weird, I'm not able to reproduce that. Milan, could you please test my __attribute__((packed)) patch as well and let me know if that still has the same warning?
Milan Crha
Comment 22 2020-03-25 03:01:13 PDT
Yes, it's there with the other patch too. $ export GIGACAGE_ENABLED=0 $ G_SLICE=always-malloc valgrind --show-leak-kinds=definite --num-callers=30 \ --leak-check=no --aspace-minaddr=0x100000000 --track-origins=yes \ ${PREFIX}/libexec/webkit2gtk-4.0/MiniBrowser That's ^^^ all I do to reproduce it.
Michael Catanzaro
Comment 23 2020-03-25 09:18:35 PDT
OK, I really can't reproduce, so I'm not the right person to fix it. Can you report a separate bug for it, please? We can use this bug report for just the first issue.
Milan Crha
Comment 24 2020-03-25 09:49:32 PDT
(In reply to Michael Catanzaro from comment #23) > Can you report a separate bug for it, please? Sure, I can, though I see both in the comment #0, thus maybe it's just something with my build. I'll wait with it for an official build with the fix (in Fedora) and I'll open a new bug (with a link to this one) if reproducible there as well (unless I forget of this). Knowing the target WebKitGTK+ version for this fix will help (once it's committed).
EWS
Comment 25 2020-03-26 02:01:59 PDT
Committed r259037: <https://trac.webkit.org/changeset/259037> All reviewed patches have been landed. Closing bug and clearing flags on attachment 394283 [details].
Radar WebKit Bug Importer
Comment 26 2020-03-26 02:02:13 PDT
Michael Catanzaro
Comment 27 2020-05-27 13:29:50 PDT
Well this is not completely fixed... r259037 avoids the warning when using bmalloc, but when running with Malloc=1, it's still there. __attribute__ ((packed)) doesn't help in this case either, so... ????? (I needed Malloc=1 to catch a memory corruption bug recently since valgrind was not complaining when using bmalloc, and have added it to Epiphany's instructions on how to run valgrind.)
Michael Catanzaro
Comment 28 2021-01-15 13:48:40 PST
Follow up in bug #220668.
Note You need to log in before you can comment on or make changes to this bug.