http://redmine.emweb.be/http://redmine.emweb.be/favicon.ico?16934085252020-10-06T16:10:16ZRedmineWt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=260942020-10-06T16:10:16ZChris Sykes
<ul></ul><p>I believe this is a data race/synchronisation issue because it does not reproduce every time (perhaps 75% of the time using a 135 MiB file).</p>
<p>Also, I'm unable to reproduce the crash if I change the thread pool size from 4 to 1 in main.cpp:</p>
<pre><code> 99 server->ioService().setThreadCount(1);
</code></pre>
<p>The other visible difference after making that change is that the upload progress % shown in the web app now updates during the upload.</p>
<p>With the thread pool count set at <code>4</code>, the upload progress stays at 0% throughout the upload, then jumps to "upload complete".</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=262592020-10-19T09:12:51ZChris Sykes
<ul></ul><p>I've not (yet) been able to reproduce the crash when using a <code>WApplication</code> rather than a <code>WQAppliction</code>,<br>
so the issue is either <em>caused</em> by or <em>significantly worsened</em> by the WtQt integration.</p>
<p>When using <code>WQApplication</code>, the crash reproduces with the DispatchThread running the Qt event loop AND<br>
also when running <code>DispatchThread::myExec()</code>.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=263422020-10-28T16:49:19ZRoel Standaertroel@emweb.be
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li></ul><p>I pushed a commit that should normally resolve this issue.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=263442020-10-28T16:50:49ZRoel Standaertroel@emweb.be
<ul><li><strong>Target version</strong> set to <i>4.5.0</i></li></ul> Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=263452020-10-28T19:21:22ZChris Sykes
<ul></ul><p>I've tested the proposed patch, but unfortunately it doesn't resolve the issue(s) for me.</p>
<p>I see the same behaviour whether running 3.7.0 + 20e2eed4 cherry-picked, or<br>
the head of the wt3 branch (which contains a few other changes on top of 3.7.0).</p>
<a name="Observed-behaviour-with-the-patch"></a>
<h3 >Observed behaviour with the patch:<a href="#Observed-behaviour-with-the-patch" class="wiki-anchor">¶</a></h3>
<p>The file uploads no longer work at all.<br><br>
The POST request is rejected with a 413 (payload too large?) error:</p>
<pre><code>127.0.0.1 - - [2020-Oct-28 18:51:28.732008] "POST /?wtd=nn7lS8UN89FAVetW&request=resource&resource=ouzmv18&rand=1 HTTP/1.1" 413 115
</code></pre>
<p>I get the same error even with really tiny files (just a few bytes). I'm guessing that<br>
the header parsing in <code>WebController::requestDataReceived</code> <em>was</em> serving a purpose<br>
after all.</p>
<a name="With-just-the-wtwithqt-portion-of-the-patch"></a>
<h3 >With just the wtwithqt portion of the patch<a href="#With-just-the-wtwithqt-portion-of-the-patch" class="wiki-anchor">¶</a></h3>
<p>I undid the <code>web/WebController.C</code> hunk of the patch, leaving the wtwithqt changes intact and re-tested.</p>
<p>Now the file uploads work again (no 413 errors), but I can reproduce the segfault when the server thread pool size is > 1.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=263462020-10-28T20:43:12ZChris Sykes
<ul></ul><p>My theory in <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: wt3: data race and other oddities during WFileUpload (Closed)" href="http://redmine.emweb.be/issues/6548">#6548</a> was that the segfault dereferencing <code>*resourceE</code> (std::string)<br>
was caused by the referenced string being invalidated when the containing<br>
<code>vector<std::string></code> in the ParameterMap was realloc'd (and moved).</p>
<p>The ParameterMap was full of duplicate parameter values, with a new dup added for<br>
every block transferred in the upload.</p>
<p>I reverted the change to <code>web/WebController.C</code>, and instead patched <code>Wt/Http/Request.C</code><br>
such that <code>Request::parseFormUrlEncoded</code> avoids appending duplicate parameter values:</p>
<pre><code>commit ae68e7e3bc68ac94250f79d64bb3da28eb0473b4
Author: Chris Sykes <chris.sykes@m-flow-tech.com>
Date: Wed Oct 28 20:13:29 2020 +0000
Request::parseFormUrlEncoded: only append changed values.
Avoid appending parameter values if they're unchanged.
diff --git a/src/Wt/Http/Request.C b/src/Wt/Http/Request.C
index b11d5880..1fe6c518 100644
--- a/src/Wt/Http/Request.C
+++ b/src/Wt/Http/Request.C
@@ -383,6 +383,15 @@ Request::~Request()
#endif
}
+static void addIfChanged(std::vector<std::string> &values,
+ const std::string &value)
+{
+ if (values.empty() || values.back() != value) {
+ values.push_back(value);
+ }
+}
+
+
#ifndef WT_TARGET_JAVA
void Request::parseFormUrlEncoded(const std::string& s,
ParameterMap& parameters)
@@ -395,7 +404,7 @@ void Request::parseFormUrlEncoded(const std::string& s,
next = s.length();
std::string key = s.substr(pos, next - pos);
Utils::inplaceUrlDecode(key);
- parameters[key].push_back(std::string());
+ addIfChanged(parameters[key], std::string());
pos = next + 1;
} else {
std::size_t amp = s.find('&', next + 1);
@@ -408,7 +417,7 @@ void Request::parseFormUrlEncoded(const std::string& s,
std::string value = s.substr(next + 1, amp - (next + 1));
Utils::inplaceUrlDecode(value);
- parameters[key].push_back(value);
+ addIfChanged(parameters[key], value);
pos = amp + 1;
}
}
</code></pre>
<p>With this applied, my <code>upload-recreate</code> ran cleanly for 20 consecutive uploads of a 342 MiB file.<br>
Usually it'd crash during almost every upload.</p>
<p>However, I'm not happy that this is actually <em>fixing</em> the underlying issue.</p>
<p>There must still be some unsafe/unsynchronised access to that ParameterMap (and values therein)<br>
for <code>WebController::updateResourceProgress</code> to be working with a pointer that gets invalidated<br>
by <code>WebController::requestDataReceived()</code> when it calls <code>Request::parseFormUrlEncoded()</code>.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=263492020-10-29T07:38:55ZRoel Standaertroel@emweb.be
<ul></ul><p>You're seeing these issues with the example you posted? I can't reproduce it myself anymore. I take it you're still using Fedora to test this? Is that version 31 still or are you now on 32 or 33? What browser are you seeing this issue with? How are you building Wt?</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=263512020-10-29T08:15:02ZRoel Standaertroel@emweb.be
<ul></ul><p>Ok I can reproduce this now.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=263572020-10-29T12:36:02ZChris Sykes
<ul><li><strong>File</strong> <a href="/attachments/3423">CMakeCache.txt</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3423/CMakeCache.txt">CMakeCache.txt</a> added</li></ul><p>Yes, I see the crash with the example project I posted (it helps to use a really big file!),<br>
and am still running Fedora 31 for the moment.</p>
<p>It reproduces for me with Wt built in Debug and RelWithDebugInfo modes.<br><br>
I've attached my cmake cache for a debug build in case it helps.</p>
<p>My primary browser is Firefox, currently v82.0 (as packaged by Fedora).</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=264812020-11-06T09:12:10ZRoel Standaertroel@emweb.be
<ul></ul><p>My latest commits should address this.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=265552020-11-16T16:37:53ZChris Sykes
<ul><li><strong>File</strong> <a href="/attachments/3476">upload-recreate.memcheck.qt.log</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3476/upload-recreate.memcheck.qt.log">upload-recreate.memcheck.qt.log</a> added</li><li><strong>File</strong> <a href="/attachments/3477">upload-recreate.memcheck.log</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3477/upload-recreate.memcheck.log">upload-recreate.memcheck.log</a> added</li></ul><p>Thanks Roel.</p>
<p>I retested with Wt 3.7.0 + your latest commits (which all apply cleanly to wt3):</p>
<ul>
<li>0001-Addressing-issue-7749-and-6548.patch</li>
<li>0002-Readded-parsing-in-requestDataReceived-because-we-do.patch</li>
<li>0003-parseFormUrlEncoded-skip-empty-parameters.patch</li>
<li>0004-Issue-7749-ensure-that-request-parameters-are-parsed.patch</li>
</ul>
<p>With them, I can no longer reproduce the crash during file-upload.</p>
<p>However, as I mentioned in <a href="#note-6">#note-6</a>, I don't think this fixes the actual race<br>
condition, it just makes it much harder to hit.</p>
<p>I ran the patched <code>upload-recreate</code> and Wt under valgrind (just memcheck,<br>
not helgrind or drd) and it complains about use-after-frees with very<br>
similar stack traces to those seen in the original crash report:</p>
<pre><code>==1338919== Thread 6 QThread:
==1338919== Invalid read of size 8
==1338919== at 0x6832C82: std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >::_M_begin() const (in /usr/local/lib/libwt.so.3.7.0)
==1338919== by 0x6832799: std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /usr/local/lib/libwt.so.3.7.0)
==1338919== by 0x6831CA6: std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >::find(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /usr/local/lib/libwt.so.3.7.0)
==1338919== by 0x6E0BC70: Wt::WebRequest::getParameterValues(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /usr/local/lib/libwt.so.3.7.0)
==1338919== by 0x6E0BC18: Wt::WebRequest::getParameter(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (in /usr/local/lib/libwt.so.3.7.0)
==1338919== by 0x6E00C77: Wt::WebController::updateResourceProgress(Wt::WebRequest*, unsigned long, unsigned long) (in /usr/local/lib/libwt.so.3.7.0)
==1338919== by 0x6E09598: boost::_mfi::mf3<void, Wt::WebController, Wt::WebRequest*, unsigned long, unsigned long>::operator()(Wt::WebController*, Wt::WebRequest*, unsigned long, unsigned long) const (in /usr/local/lib/libwt.so.3.7.0)
...
==1338919== Address 0xaa6d170 is 48 bytes inside a block of size 248 free'd
==1338919== at 0x483B0D6: operator delete(void*, unsigned long) (vg_replace_malloc.c:593)
==1338919== by 0x7B35C00: http::server::HTTPRequest::~HTTPRequest() (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7BCFB9C: http::server::WtReply::consumeRequestBody(char const*, char const*, http::server::Request::State) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7BCF6BD: http::server::WtReply::consumeData(char const*, char const*, http::server::Request::State) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7B64485: http::server::RequestParser::parseBody(http::server::Request&, boost::shared_ptr<http::server::Reply>, char*&, char*) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7B1B207: http::server::Connection::handleReadBody(boost::shared_ptr<http::server::Reply>) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7B1BA94: http::server::Connection::handleReadBody(boost::shared_ptr<http::server::Reply>, boost::system::error_code const&, unsigned long) (in /usr/local/lib/libwthttp.so.
3.7.0)
==1338919== by 0x7BC9C34: void boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptr<http::server::Reply>, boost::system::error_code const&, unsigned long>::call<boost::shared
_ptr<http::server::TcpConnection>, boost::shared_ptr<http::server::Reply>, boost::system::error_code const, unsigned long>(boost::shared_ptr<http::server::TcpConnection>&, void const*, boost:
:shared_ptr<http::server::Reply>&, boost::system::error_code const&, unsigned long&) const (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7BC984F: void boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptr<http::server::Reply>, boost::system::error_code const&, unsigned long>::operator()<boost::
shared_ptr<http::server::TcpConnection> >(boost::shared_ptr<http::server::TcpConnection>&, boost::shared_ptr<http::server::Reply>, boost::system::error_code const&, unsigned long) const (in /
usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7BC93FD: void boost::_bi::list4<boost::_bi::value<boost::shared_ptr<http::server::TcpConnection> >, boost::_bi::value<boost::shared_ptr<http::server::Reply> >, boost::arg<
1> (*)(), boost::arg<2> (*)()>::operator()<boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptr<http::server::Reply>, boost::system::error_code const&, unsigned long>, boost::_b
i::rrlist2<boost::system::error_code const&, unsigned long const&> >(boost::_bi::type<void>, boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptr<http::server::Reply>, boost::sy
stem::error_code const&, unsigned long>&, boost::_bi::rrlist2<boost::system::error_code const&, unsigned long const&>&, int) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7BC90E1: void boost::_bi::bind_t<void, boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptr<http::server::Reply>, boost::system::error_code const&, unsigned
long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptr<http::server::TcpConnection> >, boost::_bi::value<boost::shared_ptr<http::server::Reply> >, boost::arg<1> (*)(), boost::arg<2> (*)
()> >::operator()<boost::system::error_code const&, unsigned long const&>(boost::system::error_code const&, unsigned long const&) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7BC8DCA: boost::asio::detail::binder2<boost::_bi::bind_t<void, boost::_mfi::mf3<void, http::server::Connection, boost::shared_ptr<http::server::Reply>, boost::system::erro
r_code const&, unsigned long>, boost::_bi::list4<boost::_bi::value<boost::shared_ptr<http::server::TcpConnection> >, boost::_bi::value<boost::shared_ptr<http::server::Reply> >, boost::arg<1>
(*)(), boost::arg<2> (*)()> >, boost::system::error_code, unsigned long>::operator()() (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== Block was alloc'd at
==1338919== at 0x4839E86: operator new(unsigned long) (vg_replace_malloc.c:342)
==1338919== by 0x7BCFA4E: http::server::WtReply::consumeRequestBody(char const*, char const*, http::server::Request::State) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7BCF6BD: http::server::WtReply::consumeData(char const*, char const*, http::server::Request::State) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7B64485: http::server::RequestParser::parseBody(http::server::Request&, boost::shared_ptr<http::server::Reply>, char*&, char*) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7B1B207: http::server::Connection::handleReadBody(boost::shared_ptr<http::server::Reply>) (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7B1A9EB: http::server::Connection::handleReadRequest0() (in /usr/local/lib/libwthttp.so.3.7.0)
==1338919== by 0x7B1B002: http::server::Connection::handleReadRequest(boost::system::error_code const&, unsigned long) (in /usr/local/lib/libwthttp.so.3.7.0)
</code></pre>
<p>If I edit change the <code>upload-recreate</code> project to use <code>WApplication</code> directly rather than <code>WQApplication</code>,<br>
and repeat the valgrind run, I see no such errors reported.</p>
<p>Full valgrind log files are attached.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=265592020-11-16T18:23:02ZRoel Standaertroel@emweb.be
<ul></ul><p>I see, there's a use-after free of the request itself it seems?</p>
<p>So this may be really 3 issues in one, and 2 of them have been fixed.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=265622020-11-17T09:44:37ZChris Sykes
<ul></ul><blockquote>
<p>I see, there's a use-after free of the request itself it seems?</p>
</blockquote>
<p>Yes, it could well be,</p>
<p>Unfortunately I don't understand how Wt manages the lifetime of a request object.</p>
<p>Is each request (effectively) <em>moved</em> to a thread in the asio pool, then processed and then freed by that thread?</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=265632020-11-17T13:35:13ZRoel Standaertroel@emweb.be
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Feedback</i></li></ul><p>You did add the fix for the spurious wakeups to your <code>DispatchThread</code>, right? Just want to make sure of that.</p>
<p>Unlike in Qt nothing is really tied to a thread in Wt, but a request is normally only handled by one thread at a time, and it is deleted whenever that request is considered "done".</p>
<p>Could you do a Debug build? I think that'll make it so we have line numbers in the memcheck output. There are two situations in which the delete of a request happens in the <code>consumeRequestBody</code> function. One is when <code>requestDataReceived</code> returns false (in which case a 413 status code is returned to the client), the other is when we're in an error state, in which case some other 4XX or 5XX status code is returned.</p>
<p>I'm thinking possibly a delayed <code>updateResourceProgress</code> for <code>requestDataReceived</code> call N-1 that executes right after <code>requestDataReceived</code> call N deletes the request due to an error?</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=265642020-11-17T13:52:47ZChris Sykes
<ul></ul><blockquote>
<p>You did add the fix for the spurious wakeups to your DispatchThread, right? Just want to make sure of that.</p>
</blockquote>
<p>Yes, I copied over the <code>wtwithqt</code> updates into my recreate project.<br><br>
I'll double check this for you though.</p>
<blockquote>
<p>Could you do a Debug build?</p>
</blockquote>
<p>Absolutely, but will probably not have results before tomorrow as I'm a bit tied up by something else ATM.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=266602020-11-23T13:59:43ZRoel Standaertroel@emweb.be
<ul><li><strong>Target version</strong> changed from <i>4.5.0</i> to <i>4.6.0</i></li></ul> Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=267692020-12-01T17:12:20ZChris Sykes
<ul><li><strong>File</strong> <a href="/attachments/3503">upload-recreate.memcheck.log.gz</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3503/upload-recreate.memcheck.log.gz">upload-recreate.memcheck.log.gz</a> added</li></ul><p>Sorry for the delay in responding.</p>
<p>I've reproduced the errors using a <code>RelWithDebInfo</code> build.</p>
<p>Here's an extract (with the boost::asio part of the trace removed for brevity), I'll attach the full log in case it's useful:</p>
<pre><code>==4105013== Invalid read of size 8
==4105013== at 0x5832E2E: find (stl_tree.h:2570)
==4105013== by 0x5832E2E: find (stl_map.h:1194)
==4105013== by 0x5832E2E: Wt::WebRequest::getParameterValues(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (WebRequest.C:184)
==4105013== by 0x5832F28: Wt::WebRequest::getParameter(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (WebRequest.C:176)
==4105013== by 0x582DA4E: Wt::WebController::updateResourceProgress(Wt::WebRequest*, unsigned long, unsigned long) (WebController.C:473)
==4105013== by 0x583FE5B: operator() (function_template.hpp:763)
==4105013== by 0x583FE5B: Wt::WebSession::notify(Wt::WEvent const&) (WebSession.C:2240)
==4105013== by 0x489E26: Wt::WQApplication::realNotify(Wt::WEvent const&) (in /home/chris.sykes/Projects/meter/upload-recreate/build/upload-recreate)
==4105013== by 0x486622: Wt::DispatchThread::doEvent() (in /home/chris.sykes/Projects/meter/upload-recreate/build/upload-recreate)
==4105013== by 0x485F1F: Wt::DispatchObject::onEvent() (in /home/chris.sykes/Projects/meter/upload-recreate/build/upload-recreate)
==4105013== by 0x46C944: Wt::DispatchObject::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (in /home/chris.sykes/Projects/meter/upload-recreate/build/upload-recreate)
==4105013== by 0x4B137F9: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.13.2)
==4105013== by 0x4AE83B4: ??? (in /usr/lib64/libQt5Core.so.5.13.2)
==4105013== by 0x4AE8447: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib64/libQt5Core.so.5.13.2)
==4105013== by 0x4AEB48A: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib64/libQt5Core.so.5.13.2)
==4105013== Address 0x89a9af0 is 48 bytes inside a block of size 248 free'd
==4105013== at 0x483B0D6: operator delete(void*, unsigned long) (vg_replace_malloc.c:593)
==4105013== by 0x5BC6D19: http::server::WtReply::~WtReply() (WtReply.C:64)
==4105013== by 0x5BC7028: http::server::WtReply::~WtReply() (WtReply.C:78)
==4105013== by 0x46E1C2: boost::detail::sp_counted_base::release() (in /home/chris.sykes/Projects/meter/upload-recreate/build/upload-recreate)
==4105013== by 0x5B5AB4A: ~shared_count (shared_count.hpp:426)
==4105013== by 0x5B5AB4A: ~shared_ptr (shared_ptr.hpp:341)
==4105013== by 0x5B5AB4A: reset (shared_ptr.hpp:693)
==4105013== by 0x5B5AB4A: http::server::Connection::stop() (Connection.C:114)
==4105013== by 0x5BC0535: http::server::TcpConnection::stop() (TcpConnection.C:55)
==4105013== by 0x5B6430A: call<boost::shared_ptr<http::server::Connection> > (mem_fn_template.hpp:40)
==4105013== by 0x5B6430A: operator()<boost::shared_ptr<http::server::Connection> > (mem_fn_template.hpp:55)
==4105013== by 0x5B6430A: operator()<boost::_mfi::mf0<void, http::server::Connection>, boost::_bi::list0> (bind.hpp:259)
==4105013== by 0x5B6430A: operator() (bind.hpp:1294)
...
==4105013== Block was alloc'd at
==4105013== at 0x4839E86: operator new(unsigned long) (vg_replace_malloc.c:342)
==4105013== by 0x5BC80F4: http::server::WtReply::consumeRequestBody(char const*, char const*, http::server::Request::State) (WtReply.C:185)
==4105013== by 0x5BC8618: http::server::WtReply::consumeData(char const*, char const*, http::server::Request::State) (WtReply.C:145)
==4105013== by 0x5B882F7: http::server::RequestParser::parseBody(http::server::Request&, boost::shared_ptr<http::server::Reply>, char*&, char*) (RequestParser.C:218)
==4105013== by 0x5B5C851: http::server::Connection::handleReadBody(boost::shared_ptr<http::server::Reply>) (Connection.C:308)
==4105013== by 0x5B5CB4C: http::server::Connection::handleReadRequest0() (Connection.C:231)
==4105013== by 0x5BC4231: call<boost::shared_ptr<http::server::TcpConnection>, const boost::system::error_code, long unsigned int> (mem_fn_template.hpp:271)
==4105013== by 0x5BC4231: operator()<boost::shared_ptr<http::server::TcpConnection> > (mem_fn_template.hpp:286)
==4105013== by 0x5BC4231: operator()<boost::_mfi::mf2<void, http::server::Connection, const boost::system::error_code&, long unsigned int>, boost::_bi::rrlist2<const boost::system::error_code&, long unsigned int const&> > (bind.hpp:398)
==4105013== by 0x5BC4231: operator()<const boost::system::error_code&, long unsigned int const&> (bind.hpp:1318)
==4105013== by 0x5BC4231: operator() (bind_handler.hpp:164)
</code></pre>
<p>I don't see the errors on every file upload, so attempted several before terminating the process.</p>
<p>Memcheck command line:</p>
<pre><code>valgrind \
--track-fds=yes \
--track-origins=yes \
--tool=memcheck \
--leak-check=full \
--leak-resolution=high \
--log-file=upload-recreate.memcheck.log \
./build/upload-recreate --docroot="$PWD;/resources" --http-address 127.0.0.1 --http-port 8080
</code></pre>
<p>Just to reiterate, I'm <em>unable</em> to reproduce these errors using a variant<br>
of my test app that inherits WApplication rather than WQApplication. </p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=269152020-12-07T12:36:38ZRoel Standaertroel@emweb.be
<ul><li><strong>Tracker</strong> changed from <i>Support</i> to <i>Bug</i></li><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Implemented @Emweb</i></li><li><strong>Assignee</strong> set to <i>Roel Standaert</i></li><li><strong>Target version</strong> changed from <i>4.6.0</i> to <i>4.5.0</i></li></ul><p>A fix is currently under review and should be on its way for release in Wt 4.5.0.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=269162020-12-07T12:37:24ZRoel Standaertroel@emweb.be
<ul></ul><p>It will be backported to Wt 3 as well. This will likely be the last release of Wt 3.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=271602020-12-10T15:20:53ZRoel Standaertroel@emweb.be
<ul><li><strong>Status</strong> changed from <i>Implemented @Emweb</i> to <i>Resolved</i></li></ul><p>I pushed what should hopefully be the final fix for this issue.</p>
Wt - Bug #7749: Crash (SEGV) when using WFileUpload within WQApplicationhttp://redmine.emweb.be/issues/7749?journal_id=273422020-12-17T12:48:24ZRoel Standaertroel@emweb.be
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul>