Re: Valgrind 'invalid read of size 4' with LUAJIT_USE_VALGRIND defined
- From: Thomas Schilling <nominolo@xxxxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Tue, 19 Mar 2013 22:17:11 +0100
I found a good way of finding out where exactly things are going wrong
is by getting valgrind to stop at an error and then look at the exact
place via GDB:
http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-gdb
On 19 March 2013 22:02, John Craws <john.craws@xxxxxxxxx> wrote:
> Hello,
>
> We recently tried to switch from the standard Lua library to LuaJIT
> 2.0.1. The modifications were relatively painless and test results
> indicated that the original functionality was preserved.
>
> However, we see a number of 'invalid read of size 4' warnings when we
> run our application under valgrind. The same tests did not generate
> those messages when run using the original Lua library.
>
> I have searched the mailing list for potential answers but did not
> find anything that led to a solution.
>
> I have tried modifying the Makefile to enable LUAJIT_USE_VALGRIND,
> changing the optimization level from O2 to O, and enabling '-g' via
> CCDEBUG.
>
> Only enabling LUAJIT_USE_VALGRIND was not sufficient. I still see the
> invalid reads. I tried to enable '-g' without LUAJIT_USE_VALGRIND to
> get more info, but the '-g' makes the warnings disappear.
>
> I am not allowed to post code and I understand that this drastically
> limits any possibility of getting hints on a potential fix, but I
> still thought I'd ask if anyone has seen a similar situation before
> with LuaJIT 2.0.1.
>
> The invalid reads occur mostly with lua_pushstring(). Parameters to
> the call are a lua_State pointer (member variable) and a const char *
> that is created from a call to an std::string's c_str (). The
> lua_pushstring documentation indicates that Lua will make an internal
> copy of the string and that it can be freed after the call returns so
> I don't think there is any problem with the lifetime of that pointer.
>
> Here's a snippet
>
> ----
> ==16128== Thread 11:
> ==16128== Invalid read of size 4
> ==16128== at 0xF8C7AA6: ??? (in
> /home/jcraws/opt/stable/head/luajit/2.0.1/lib/libluajit-5.1.so.2.0.1)
> ==16128== by 0xF8CF551: lua_pushstring (in
> /home/jcraws/opt/stable/head/luajit/2.0.1/lib/libluajit-5.1.so.2.0.1)
> ==16128== by 0x5800B6A:
> van::cLuaStringMethodParameter::Push(van::cLuaInstance const&) const
> (LuaStringMethodParameter.cpp:22)
> ==16128== by 0x5801433:
> van::cLuaTableMethodParameter::Push(van::cLuaInstance const&) const
> (LuaTableMethodParameter.cpp:68)
> ==16128== by 0x5801433:
> van::cLuaTableMethodParameter::Push(van::cLuaInstance const&) const
> (LuaTableMethodParameter.cpp:68)
> ==16128== by 0x57F1811: van::cLuaMethod::Execute(van::cLuaInstance
> const&) (LuaMethod.cpp:202)
> ==16128== by 0x57F2FE3:
> van::cLuaPluginContentIdentification::IdentifyContent(_GStaticRWLock*,
> van::cPluginRequestParameter const*, van::cPluginResponseParameter
> const*, van::cPluginContentDescriptionParameter*)
> (LuaPluginContentIdentification.cpp:73)
> ==16128== by 0x5C80556:
> van::cSessionPluginHandler::IdentifyContent(van::cIcapMessageRequest
> const*, van::cEndpoint const*) (SessionPluginHandler.cpp:105)
> ==16128== by 0x5C2EE02:
> van::cIcapRouteService::ProcessRespmodRequestPrivate(van::cIcapMessageRequest
> const*) (IcapRouteService.cpp:179)
> ==16128== by 0x5C2E9F2:
> van::cIcapRouteService::ProcessRespmodRequest(van::cIcapMessageRequest
> const*) (IcapRouteService.cpp:94)
> ==16128== by 0x5C17951:
> van::cIcapServer::ProcessRespmodRequest(van::cIcapMessageRequest
> const*) (IcapServer.cpp:532)
> ==16128== by 0x5C165C0:
> van::cIcapServer::ProcessRequest(van::cIcapMessage const*)
> (IcapServer.cpp:369)
> ==16128== Address 0x19a31e7c is 28 bytes inside a block of size 31 alloc'd
> ==16128== at 0x4C28B35: operator new(unsigned long)
> (vg_replace_malloc.c:261)
> ==16128== by 0x1132BDE8: std::string::_Rep::_S_create(unsigned
> long, unsigned long, std::allocator<char> const&) (new_allocator.h:89)
> ==16128== by 0x1132CAE4: char*
> std::string::_S_construct<char*>(char*, char*, std::allocator<char>
> const&, std::forward_iterator_tag) (basic_string.tcc:139)
> ==16128== by 0x1132CCC8: std::basic_string<char,
> std::char_traits<char>, std::allocator<char>
>>::basic_string(std::string const&, unsigned long, unsigned long)
> (basic_string.h:1543)
> ==16128== by 0x61C73AE:
> van::cIcapMessageScribe::ParseMessageHeaders(van::cIcapMessage*,
> std::vector<std::string, std::allocator<std::string> >&)
> (basic_string.h:2003)
> ==16128== by 0x61CDDB6:
> van::cIcapMessageScribe::ParseDefault(std::string const&,
> van::cIcapMessage**, bool&, unsigned int&, unsigned int)
> (IcapMessageScribe.cpp:783)
> ==16128== by 0x61CE1D8: van::cIcapMessageScribe::Parse(char const*,
> unsigned long, van::cIcapMessage**, unsigned int&, unsigned int)
> (IcapMessageScribe.cpp:483)
> ==16128== by 0x61D46EB: van::cIcapConnection::Receive(bool&)
> (IcapConnection.cpp:397)
> ==16128== by 0x5C14CA7:
> van::cIcapServer::HandleConnection(cVanTcpConnection*, std::string
> const&) (IcapServer.cpp:94)
> ==16128== by 0x40D4E5: van_handle_icap_connection(void*, void*)
> (vanvideooptimizer.cpp:147)
> ==16128== by 0xDFB9E4E: g_thread_pool_thread_proxy (gthreadpool.c:265)
> ==16128== by 0xDFB8143: g_thread_create_proxy (gthread.c:635)
>
> ----
>
> Any help would be appreciated.
>
> Thanks,
>
> John Craws
>
Other related posts:
