|
From: Jonatan W. <jo...@vo...> - 2013-03-26 13:30:21
|
Feature-request:
Add backtrace to output for these warnings:
"Warning: set address range perms: large range
[0x4c339040, 0x206094130) (undefined)"
Explanation:
This was a large allocation which ate up all my memory when debugging
with valgrind making it hard for me to find where it happened.
The reason was an undefined integer in a class (uninitialized memory).
Valgrind only gives this one line warning (which is good), but
it would also be nice if it would give a backtrace for this...
Might have helped me to track down this bug sooner :)
--
With kind regards
Jonatan Wallmander
Vovoid Media Technologies AB
|
|
From: Philippe W. <phi...@sk...> - 2013-03-26 21:52:29
|
On Tue, 2013-03-26 at 14:30 +0100, Jonatan Wallmander wrote:
> Feature-request:
> Add backtrace to output for these warnings:
> "Warning: set address range perms: large range
> [0x4c339040, 0x206094130) (undefined)"
Probably not difficult to implement, however, see below ...
>
>
> Explanation:
>
> This was a large allocation which ate up all my memory when debugging
> with valgrind making it hard for me to find where it happened.
>
> The reason was an undefined integer in a class (uninitialized memory).
However, the root cause is that Valgrind should report an error when
malloc is called with a undefined size argument.
>
> Valgrind only gives this one line warning (which is good), but
> it would also be nice if it would give a backtrace for this...
>
> Might have helped me to track down this bug sooner :)
The 'large range' message was produced thanks to some luck.
The best would be to file a bug in bugzilla, for the false negative
caused by code such as:
{
size_t undef;
char *p = malloc (undef);
}
Thanks
Philippe
|
|
From: Philippe W. <phi...@sk...> - 2013-04-04 21:13:56
|
On Tue, 2013-03-26 at 22:52 +0100, Philippe Waroquiers wrote:
> The best would be to file a bug in bugzilla, for the false negative
> caused by code such as:
>
> {
> size_t undef;
> char *p = malloc (undef);
> }
Too late to file a bug in bugzilla :).
An improvement has been committed in revision 13361.
False negative in malloc lib replaced functions should be solved now.
E.g. a call to malloc with undefined size will now cause an error
to be detected by memcheck.
Philippe
|
|
From: Jonatan W. <jo...@vo...> - 2013-04-04 22:02:59
|
\o/
With kind regards / Med vänliga hälsningar
Jonatan Wallmander
Vovoid Media Technologies AB
On 04/04/2013 11:13 PM, Philippe Waroquiers wrote:
> On Tue, 2013-03-26 at 22:52 +0100, Philippe Waroquiers wrote:
>
>> The best would be to file a bug in bugzilla, for the false negative
>> caused by code such as:
>>
>> {
>> size_t undef;
>> char *p = malloc (undef);
>> }
> Too late to file a bug in bugzilla :).
> An improvement has been committed in revision 13361.
> False negative in malloc lib replaced functions should be solved now.
> E.g. a call to malloc with undefined size will now cause an error
> to be detected by memcheck.
>
> Philippe
>
>
|
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2013-04-09 17:54:11
|
Sorry for a lengthy post, but I got the following output from valgrind/memcheck while I was testing mozilla thunderbird using its test framework, "make mozmill". By running thunderbird under memgrind while it goes through tests, I can detect where some variables are not initialized and used, or outright memory access violations. While I was doing it, I got the following log: My question and request: 1. Can this unfamiliar clone be supported? 2. The dump from valgrind/memcheck afterward, i.e., the print out of the status of threads in the program with brief stack traces related to task synchronization looks so useful that, I wonder, it merits a switch to print that dump when memory error is detected during memcheck. Can you add this feature (enabled by a command line option)? Here is a the relevant log. I trimmed the strange very long repetition that follows PR_WaitCondVar in the stack for each thread. I think there is a bug in the print routine or something. We can skip printing the same information again and again. You can see that task 1 is the main Thunderbird thread, and other information from this information and without the full feature of helgrind, we may glean the overview of thread activity from this stack dump. Thus the request for outputting such information when memgrind detectes memory error. TB seems to be trying to generate a so called crash dump (triggered by other cause( and it tries to hard to do so when it encounteres this valgrind/memcheck limitation. Actually, from other trace data that precedes the excerpt below, the Lock() routine near the top of the stack, > ==803== by 0xAD79110: mozilla::Mutex::Lock() (BlockingResourceBase.cpp:227) caused a null pointer reference inside the thread library, and that triggered the google's breakpad exception handler to be invoked. So this happened not in the smooth processing of a program. ==803== ==803== Unsupported clone() flags: 0x800600 ==803== ==803== The only supported clone() uses are: ==803== - via a threads library (LinuxThreads or NPTL) ==803== - via the implementation of fork or vfork ==803== - for the Quadrics Elan3 user-space driver ==803== ==803== Valgrind detected that your program requires ==803== the following unimplemented functionality: ==803== Valgrind does not support general clone(). ==803== This may be because the functionality is hard to implement, ==803== or because no reasonable program would behave this way, ==803== or because nobody has yet needed it. In any case, let us know at ==803== www.valgrind.org and/or try to work around the problem, if you can. ==803== ==803== Valgrind has to exit now. Sorry. Bye! ==803== sched status: <=== I have not asked for the following dump, but valgrind provided it! running_tid=1 Thread 1: status = VgTs_Runnable ==803== at 0x8BA9823: google_breakpad::ExceptionHandler::GenerateDump(google_breakpad::ExceptionHandler::CrashContext*) (linux_syscall_support.h:1685) ==803== by 0x8BA9B7F: google_breakpad::ExceptionHandler::HandleSignal(int, siginfo*, void*) (exception_handler.cc:412) ==803== by 0x8BA9C5F: google_breakpad::ExceptionHandler::SignalHandler(int, siginfo*, void*) (exception_handler.cc:326) ==803== by 0x405B74F: ??? (in /lib/i386-linux-gnu/i686/cmov/libpthread-2.13.so) ==803== by 0xAD79110: mozilla::Mutex::Lock() (BlockingResourceBase.cpp:227) ==803== by 0x8BA08D8: CrashReporter::TakeMinidumpForChild(unsigned int, nsIFile**, unsigned int*) (Mutex.h:153) ==803== by 0x8B5FA48: XRE_TakeMinidumpForChild (nsEmbedFunctions.cpp:234) ==803== by 0xA8F60A6: mozilla::dom::PContentParent::TakeMinidump(nsIFile**, unsigned int*) const (PPluginModuleParent.cpp:1588) ==803== by 0xA8AA365: mozilla::plugins::PluginModuleParent::ProcessFirstMinidump() (PluginModuleParent.cpp:649) ==803== by 0xA8AA5E7: mozilla::plugins::PluginModuleParent::ActorDestroy(mozilla::ipc::IProtocolManager<mozilla::ipc::RPCChannel::RPCListener>::ActorDestroyReason) (PluginModuleParent.cpp:707) ==803== by 0xA8F829D: mozilla::plugins::PPluginModuleParent::DestroySubtree(mozilla::ipc::IProtocolManager<mozilla::ipc::RPCChannel::RPCListener>::ActorDestroyReason) (PPluginModuleParent.cpp:1654) ==803== by 0xA8F8309: mozilla::plugins::PPluginModuleParent::OnChannelError() (PPluginModuleParent.cpp:1486) ==803== by 0xA8BA65F: mozilla::ipc::AsyncChannel::NotifyMaybeChannelError() (AsyncChannel.cpp:570) ==803== by 0xA8BAD1E: mozilla::ipc::AsyncChannel::OnNotifyMaybeChannelError() (AsyncChannel.cpp:535) ==803== by 0xA8685CE: RunnableMethod<mozilla::dom::TabChild, void (mozilla::dom::TabChild::*)(), Tuple0>::Run() (tuple.h:383) ==803== by 0xAE3A575: MessageLoop::RunTask(Task*) (message_loop.cc:334) ==803== by 0xAE3C274: MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) (message_loop.cc:342) ==803== by 0xAE3C4EE: MessageLoop::DoWork() (message_loop.cc:442) ==803== by 0xA8C2B74: mozilla::ipc::DoWorkRunnable::Run() (MessagePump.cpp:42) ==803== by 0xADE7896: nsThread::ProcessNextEvent(bool, bool*) (nsThread.cpp:627) ==803== by 0xAE170E3: NS_InvokeByIndex (in /COMM-CENTRAL/objdir-tb3/mozilla/toolkit/library/libxul.so) ==803== by 0x9D9791F: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:2953) ==803== by 0x9DA0BE8: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1459) ==803== by 0xB49BFF7: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:338) ==803== by 0xB48F2A3: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode, bool) (jsinterp.cpp:2393) ==803== by 0xB49AD7E: js::RunScript(JSContext*, js::StackFrame*) (jsinterp.cpp:365) ==803== by 0xB49BEED: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jsinterp.cpp:422) ==803== by 0xB49D297: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:135) ==803== by 0xB4FD952: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:482) ==803== by 0xB5CBCF6: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:486) ==803== by 0xB5035DF: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2614) ==803== by 0xB503704: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3182) ==803== by 0xB49C357: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:338) ==803== by 0xB48F2A3: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode, bool) (jsinterp.cpp:2393) ==803== by 0xB49AD7E: js::RunScript(JSContext*, js::StackFrame*) (jsinterp.cpp:365) ==803== by 0xB49BEED: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jsinterp.cpp:422) ==803== by 0xB49D297: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:135) ==803== by 0xB4FD952: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:482) ==803== by 0xB5CBCF6: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:486) ==803== by 0xB5035DF: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2614) ==803== by 0xB503704: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3182) ==803== by 0xB49C357: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:338) ==803== by 0xB48F2A3: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode, bool) (jsinterp.cpp:2393) ==803== by 0xB49AD7E: js::RunScript(JSContext*, js::StackFrame*) (jsinterp.cpp:365) ==803== by 0xB49BEED: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jsinterp.cpp:422) ==803== by 0xB41D42F: js_fun_apply(JSContext*, unsigned int, JS::Value*) (jsinterp.h:135) ==803== by 0xB49BFF7: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:338) ==803== by 0xB49D297: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:135) ==803== by 0xB4FD952: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:482) ==803== by 0xB5CBCF6: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:486) ==803== by 0xB5035DF: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2614) ==803== by 0xB503704: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3182) ==803== by 0xB49C357: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:338) ==803== by 0xB48F2A3: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode, bool) (jsinterp.cpp:2393) ==803== by 0xB49AD7E: js::RunScript(JSContext*, js::StackFrame*) (jsinterp.cpp:365) ==803== by 0xB49BEED: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jsinterp.cpp:422) ==803== by 0xB49D297: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:135) ==803== by 0xB4FD952: js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:482) ==803== by 0xB5CBCF6: js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jswrapper.cpp:486) ==803== by 0xB5035DF: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (jsproxy.cpp:2614) ==803== by 0xB503704: proxy_Call(JSContext*, unsigned int, JS::Value*) (jsproxy.cpp:3182) ==803== by 0xB49C357: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:338) ==803== by 0xB48F2A3: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode, bool) (jsinterp.cpp:2393) ==803== by 0xB49AD7E: js::RunScript(JSContext*, js::StackFrame*) (jsinterp.cpp:365) ==803== by 0xB49B300: js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) (jsinterp.cpp:553) ==803== by 0xB49B6AC: js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) (jsinterp.cpp:593) ==803== by 0xB37B0DE: JS::Evaluate(JSContext*, JS::Handle<JSObject*>, JS::CompileOptions, unsigned short const*, unsigned int, JS::Value*) (jsapi.cpp:5658) ==803== by 0x9D4766D: xpc_EvalInSandbox(JSContext*, JSObject*, nsAString_internal const&, char const*, int, JSVersion, bool, JS::Value*) (XPCComponents.cpp:3959) ==803== by 0x9D4BEB2: nsXPCComponents_Utils::EvalInSandbox(nsAString_internal const&, JS::Value const&, JS::Value const&, JS::Value const&, int, JSContext*, unsigned char, JS::Value*) (XPCComponents.cpp:3899) ==803== by 0xAE170E3: NS_InvokeByIndex (in /COMM-CENTRAL/objdir-tb3/mozilla/toolkit/library/libxul.so) ==803== by 0x9D9791F: XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (XPCWrappedNative.cpp:2953) ==803== by 0x9DA0BE8: XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (XPCWrappedNativeJSOps.cpp:1459) ==803== by 0xB49BFF7: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jscntxtinlines.h:338) ==803== by 0xB48F2A3: js::Interpret(JSContext*, js::StackFrame*, js::InterpMode, bool) (jsinterp.cpp:2393) ==803== by 0xB49AD7E: js::RunScript(JSContext*, js::StackFrame*) (jsinterp.cpp:365) ==803== by 0xB49BEED: js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (jsinterp.cpp:422) ==803== by 0xB49D297: js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (jsinterp.h:135) ==803== by 0xB37D81A: JS_CallFunctionValue(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::Value*) (jsapi.cpp:5854) ==803== by 0x9D898BB: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJSClass.cpp:1433) ==803== by 0x9D7DC24: nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (XPCWrappedJS.cpp:578) ==803== by 0xAE17CCC: PrepareAndDispatch (xptcstubs_gcc_x86_unix.cpp:60) ==803== by 0x8BD473A: nsInputStreamPump::OnStateTransfer() (nsInputStreamPump.cpp:484) ==803== by 0x8BD55CE: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (nsInputStreamPump.cpp:372) ==803== by 0xADC3A75: nsInputStreamReadyEvent::Run() (nsStreamUtils.cpp:82) ==803== by 0xADE7896: nsThread::ProcessNextEvent(bool, bool*) (nsThread.cpp:627) ==803== by 0xAD74328: NS_ProcessNextEvent(nsIThread*, bool) (nsThreadUtils.cpp:238) ==803== by 0xA8C346A: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (MessagePump.cpp:82) ==803== by 0xAE3A432: MessageLoop::RunInternal() (message_loop.cc:216) ==803== by 0xAE3A44E: MessageLoop::RunHandler() (message_loop.cc:209) ==803== by 0xAE3A7A9: MessageLoop::Run() (message_loop.cc:183) ==803== by 0xA223970: nsBaseAppShell::Run() (nsBaseAppShell.cpp:163) ==803== by 0x9F31781: nsAppStartup::Run() (nsAppStartup.cpp:288) ==803== by 0x8B548B8: XREMain::XRE_mainRun() (nsAppRunner.cpp:3880) ==803== by 0x8B55DE2: XREMain::XRE_main(int, char**, nsXREAppData const*) (nsAppRunner.cpp:3947) ==803== by 0x8B56182: XRE_main (nsAppRunner.cpp:4152) ==803== by 0x8049B1C: main (nsMailApp.cpp:111) Thread 2: status = VgTs_WaitSys ==803== at 0x4269B27: syscall (syscall.S:31) ==803== by 0xAE338DF: epoll_wait (epoll_sub.c:51) ==803== by 0xAE33534: epoll_dispatch (epoll.c:407) ==803== by 0xAE2E0BC: event_base_loop (event.c:1607) ==803== by 0xAE48628: base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) (message_pump_libevent.cc:332) ==803== by 0xAE3A432: MessageLoop::RunInternal() (message_loop.cc:216) ==803== by 0xAE3A44E: MessageLoop::RunHandler() (message_loop.cc:209) ==803== by 0xAE3A7A9: MessageLoop::Run() (message_loop.cc:183) ==803== by 0xAE3FFAD: base::Thread::ThreadMain() (thread.cc:156) ==803== by 0xAE49259: ThreadFunc(void*) (platform_thread_posix.cc:39) ==803== by 0x4052C38: start_thread (pthread_create.c:304) ==803== by 0x426D78D: clone (clone.S:130) <=== Thread 3: status = VgTs_WaitSys ==803== at 0x425FD96: poll (poll.c:87) ==803== by 0x4725257: _pr_poll_with_poll (ptio.c:3920) ==803== by 0x4728FF8: PR_Poll (ptio.c:4322) ==803== by 0x8C089FD: nsSocketTransportService::DoPollIteration(bool) (nsSocketTransportService2.cpp:772) ==803== by 0x8C08DC0: nsSocketTransportService::Run() (nsSocketTransportService2.cpp:642) ==803== by 0xADE7896: nsThread::ProcessNextEvent(bool, bool*) (nsThread.cpp:627) ==803== by 0xAD74328: NS_ProcessNextEvent(nsIThread*, bool) (nsThreadUtils.cpp:238) ==803== by 0xADE8C13: nsThread::ThreadFunc(void*) (nsThread.cpp:265) ==803== by 0x472A766: _pt_root (ptthread.c:191) ==803== by 0x4052C38: start_thread (pthread_create.c:304) ==803== by 0x426D78D: clone (clone.S:130) <=== Thread 4: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x65B7A27: ??? ==803== by 0x65B7A27: ??? [... many repetition of the same line ... Maybe valgrind/memcheck has a bug here.] ==803== by 0x65B7A27: ??? ==803== by 0x65B7A27: ??? Thread 5: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x6C4C237: ??? ==803== by 0x6C4C237: ??? [... many repetition of the same line ... Maybe valgrind/memcheck has a bug here. ] ==803== by 0x6C4C237: ??? ==803== by 0x6C4C237: ??? Thread 6: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x6C73A87: ??? ==803== by 0x6C73A87: ??? [... many repetition of the same line ...] ==803== by 0x6C73A87: ??? ==803== by 0x6C73A87: ??? Thread 7: status = VgTs_WaitSys ==803== at 0x4057703: pthread_cond_timedwait@@GLIBC_2.3.2 (pthread_cond_timedwait.S:237) ==803== by 0x2CED8A87: ??? Thread 8: status = VgTs_WaitSys ==803== at 0x4057703: pthread_cond_timedwait@@GLIBC_2.3.2 (pthread_cond_timedwait.S:237) ==803== by 0xFDBC8AF: ??? (in /usr/share/icons/gnome/icon-theme.cache) Thread 9: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0xD827A27: ??? ==803== by 0xD827A27: ??? ==803== by 0xD827A27: ??? ==803== by 0xD827A27: ??? [... many repetion of the same line. ] ==803== by 0xD827A27: ??? ==803== by 0xD827A27: ??? Thread 10: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0xDCB5BB7: ??? ==803== by 0xDCB5BB7: ??? [... repetition ...] ==803== by 0xDCB5BB7: ??? ==803== by 0xDCB5BB7: ??? Thread 11: status = VgTs_WaitSys ==803== at 0x4057703: pthread_cond_timedwait@@GLIBC_2.3.2 (pthread_cond_timedwait.S:237) ==803== by 0x31368E77: ??? Thread 12: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0xCE2171F: ??? ==803== by 0xCE2171F: ??? [... repetion ...] ==803== by 0xCE2171F: ??? ==803== by 0xCE2171F: ??? Thread 13: status = VgTs_WaitSys ==803== at 0x425FD96: poll (poll.c:87) ==803== by 0x4CD413A: g_poll (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4) ==803== by 0x4CC59EF: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4) ==803== by 0x4CC5ECA: g_main_loop_run (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4) ==803== by 0x426D78D: clone (clone.S:130) Thread 14: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x439F417: ??? ==803== by 0x439F417: ??? [... repetition ...] ==803== by 0x439F417: ??? ==803== by 0x439F417: ??? Thread 15: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x133DA6CF: ??? ==803== by 0x133DA6CF: ??? [... repetition ...] ==803== by 0x133DA6CF: ??? ==803== by 0x133DA6CF: ??? Thread 16: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x15179DC7: ??? ==803== by 0x15179DC7: ??? [... repetition ...] ==803== by 0x15179DC7: ??? ==803== by 0x15179DC7: ??? Thread 17: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x148B5EFF: ??? ==803== by 0x148B5EFF: ??? [... repetition ...] ==803== by 0x148B5EFF: ??? ==803== by 0x148B5EFF: ??? Thread 18: status = VgTs_WaitSys ==803== at 0x425FD96: poll (poll.c:87) ==803== by 0x4CD413A: g_poll (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4) ==803== by 0x4CC59EF: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4) ==803== by 0x4CC5ECA: g_main_loop_run (in /lib/i386-linux-gnu/libglib-2.0.so.0.3200.4) ==803== by 0x426D78D: clone (clone.S:130) <=== CAN THIS BE THE CAUSE of VALGRIND early exit? Thread 19: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x158CADCF: ??? ==803== by 0x158CADCF: ??? [... repetition ...] ==803== by 0x158CADCF: ??? ==803== by 0x158CADCF: ??? Thread 20: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0xE37164F: ??? ==803== by 0xE37164F: ??? [... repetition...] ==803== by 0xE37164F: ??? ==803== by 0xE37164F: ??? Thread 21: status = VgTs_WaitSys ==803== at 0x4057703: pthread_cond_timedwait@@GLIBC_2.3.2 (pthread_cond_timedwait.S:237) ==803== by 0x2348322F: ??? Thread 22: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0x142FADAF: ??? ==803== by 0x142FADAF: ??? [... repetition ...] ==803== by 0x142FADAF: ??? ==803== by 0x142FADAF: ??? Thread 23: status = VgTs_WaitSys ==803== at 0x4057703: pthread_cond_timedwait@@GLIBC_2.3.2 (pthread_cond_timedwait.S:237) ==803== by 0x280C55A7: ??? Thread 26: status = VgTs_WaitSys ==803== at 0x405720A: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:153) ==803== by 0x472387C: PR_WaitCondVar (ptsynch.c:385) ==803== by 0xCC6C667: ??? ==803== by 0xCC6C667: ??? [... repetition...] ==803== by 0xCC6C667: ??? ==803== by 0xCC6C667: ??? Done sleeping... ==1214== |
|
From: Julian S. <js...@ac...> - 2013-04-09 18:42:09
|
On 04/09/2013 07:54 PM, ISHIKAWA,chiaki wrote: > Sorry for a lengthy post, but > I got the following output from valgrind/memcheck while > I was testing mozilla thunderbird using its test framework, "make mozmill". Did you use --smc-check=all-non-file? If not, can you retry with that please? J |
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2013-04-10 00:27:52
|
(2013/04/10 3:41), Julian Seward wrote: > On 04/09/2013 07:54 PM, ISHIKAWA,chiaki wrote: >> Sorry for a lengthy post, but >> I got the following output from valgrind/memcheck while >> I was testing mozilla thunderbird using its test framework, "make mozmill". > > Did you use --smc-check=all-non-file? If not, can you retry with that please? > > J > I used --smc-check=all-non-file. The following is how TB was invoked under valgrind in my modified "make mozmill" setup. (sorry for unintentional linebreaks. The whole lines is actually on one line.) valgrind --trace-children=yes --smc-check=all-non-file --gen-suppressions=all --track-origins=yes --malloc-fill=0xA5 --free-fill=0xC3 --leak-check=full --num-callers=50 --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/cross-architecture.sup --suppressions=$HOME/TB-NEW/TB-3HG/new-src/mozilla/build/valgrind/i386-redhat-linux-gnu.sup --suppressions=$HOME/Dropbox/myown.sup --show-possibly-lost=no /COMM-CENTRAL/objdir-tb3/mozilla/dist/bin/thunderbird-bin -profile /COMM-CENTRAL/objdir-tb3/mozilla/_tests/mozmill/mozmillprofile -jsbridge 24242 -foreground TIA |
|
From: John R. <jr...@bi...> - 2013-04-09 19:00:54
|
> I got the following output from valgrind/memcheck while
> I was testing mozilla thunderbird using its test framework, "make mozmill".
> 1. Can this unfamiliar clone be supported?
> ==803== Unsupported clone() flags: 0x800600
Perhaps. Here is an analysis plus something that you can attempt:
----- /usr/include/bits/sched.h:
# define CLONE_VM 0x00000100 /* Set if VM shared between processes. */
# define CLONE_FS 0x00000200 /* Set if fs info shared between processes. */
# define CLONE_FILES 0x00000400 /* Set if open files shared between processes. */
# define CLONE_VFORK 0x00004000 /* Set if the parent wants the child to
wake it up on mm_release. */
# define CLONE_UNTRACED 0x00800000 /* Set if the tracing process can't
force CLONE_PTRACE on this clone. */
----- coregrind/m_syswrap/syswrap-amd64-linux.c
/* Only look at the flags we really care about */
switch (cloneflags & (VKI_CLONE_VM | VKI_CLONE_FS
| VKI_CLONE_FILES | VKI_CLONE_VFORK)) {
case VKI_CLONE_VM | VKI_CLONE_FS | VKI_CLONE_FILES:
/* thread creation */
<<snip>>
case VKI_CLONE_VFORK | VKI_CLONE_VM: /* vfork */
/* FALLTHROUGH - assume vfork == fork */
cloneflags &= ~(VKI_CLONE_VFORK | VKI_CLONE_VM);
case 0: /* plain fork */
<<snip>>
default:
/* should we just ENOSYS? */
VG_(message)(Vg_UserMsg,
"Unsupported clone() flags: 0x%lx\n", ARG1);
-----
So by omitting VKI_CLONE_VM from flags then mozilla is *not* making a new thread,
but instead is making a new process via "plain fork". However, a plain fork
with CLONE_FS and CLONE_FILES set (that is, a separate process that *shares*
filesystem info and open files with its parent) is not something that coregrind
understands. I'm not sure I understand it, either. What do the mozilla comments
say? What is mozilla trying to accomplish by clone() with those peculiar flags?
After that, then the first thing to try is to tail-merge mozilla's special case
into coregrind's "plain fork":
case VKI_CLONE_FS | VKI_CLONE_FILES: /* DEBUG: mozilla special case */
/* FALLTHROUGH into plain fork */
case 0: /* plain fork */
Re-build valgrind (including "make install") and try that.
--
|
|
From: ISHIKAWA,chiaki <ish...@yk...> - 2013-04-10 00:41:57
|
My comment inline:
(2013/04/10 4:01), John Reiser wrote:
>> I got the following output from valgrind/memcheck while
>> I was testing mozilla thunderbird using its test framework, "make mozmill".
>
>> 1. Can this unfamiliar clone be supported?
>
>> ==803== Unsupported clone() flags: 0x800600
>
> Perhaps. Here is an analysis plus something that you can attempt:
>
> ----- /usr/include/bits/sched.h:
> # define CLONE_VM 0x00000100 /* Set if VM shared between processes. */
>
> # define CLONE_FS 0x00000200 /* Set if fs info shared between processes. */
> # define CLONE_FILES 0x00000400 /* Set if open files shared between processes. */
>
> # define CLONE_VFORK 0x00004000 /* Set if the parent wants the child to
> wake it up on mm_release. */
>
> # define CLONE_UNTRACED 0x00800000 /* Set if the tracing process can't
> force CLONE_PTRACE on this clone. */
>
> ----- coregrind/m_syswrap/syswrap-amd64-linux.c
I take that 32-bit version behaves the same.
(I am using 32-bit Debian GNU/Linux.)
> /* Only look at the flags we really care about */
> switch (cloneflags & (VKI_CLONE_VM | VKI_CLONE_FS
> | VKI_CLONE_FILES | VKI_CLONE_VFORK)) {
> case VKI_CLONE_VM | VKI_CLONE_FS | VKI_CLONE_FILES:
> /* thread creation */
> <<snip>>
>
> case VKI_CLONE_VFORK | VKI_CLONE_VM: /* vfork */
> /* FALLTHROUGH - assume vfork == fork */
> cloneflags &= ~(VKI_CLONE_VFORK | VKI_CLONE_VM);
>
> case 0: /* plain fork */
> <<snip>>
>
> default:
> /* should we just ENOSYS? */
> VG_(message)(Vg_UserMsg,
> "Unsupported clone() flags: 0x%lx\n", ARG1);
> -----
>
> So by omitting VKI_CLONE_VM from flags then mozilla is *not* making a new thread,
> but instead is making a new process via "plain fork". However, a plain fork
> with CLONE_FS and CLONE_FILES set (that is, a separate process that *shares*
> filesystem info and open files with its parent) is not something that coregrind
> understands. I'm not sure I understand it, either. What do the mozilla comments
> say? What is mozilla trying to accomplish by clone() with those peculiar flags?
I have no idea, but I think mozilla thunderbird was trying to invoke its crash
reporter after detecting memory error on its own using a signal handler via SIGSEGV or something.
>
> After that, then the first thing to try is to tail-merge mozilla's special case
> into coregrind's "plain fork":
>
> case VKI_CLONE_FS | VKI_CLONE_FILES: /* DEBUG: mozilla special case */
> /* FALLTHROUGH into plain fork */
>
> case 0: /* plain fork */
>
> Re-build valgrind (including "make install") and try that.
>
Thank you for the suggestion. I will try this.
*BUT*, this memory error may or may not happen during "make mozmill" always.
It seems that it can be caused by memory corruption due to races and thus
highly timing dependent.
I encountered the error for the first time during testing mozilla thunderbird
since last November when I began tinkering with thunderbird and valgrind.
So I am not holding a breath, but when my run encounters another manifestation of the bug
and valgrind proceeds further with the above change, I will report it.
BTW, do you have any idea about "adding the dump of thread info about
all the threads (maybe enabled on/off by a command switch)
when valgrind/memcheck detects serious memory error "?
After fixing the strange repetition of same addresses (numerical address),
which seems to be a bug, or we can simply omit the repetition of the same numbers after a few times,
the dump will be very useful.
I learned about the status of the threads in thunderbird
for the first time after seeing the dump myself :-)
(I am not the author of TB, and am just trying to figure out where some crashes I experienced
in real life could have been caused, so that people in the know could home
in the buggy places to fix them.)
Thank you, valgrind community, for sharing this wonderful tool!
|
|
From: John R. <jr...@bi...> - 2013-04-10 01:46:35
|
> BTW, do you have any idea about "adding the dump of thread info about > all the threads (maybe enabled on/off by a command switch) > when valgrind/memcheck detects serious memory error "? Distinguishing "serious memory error" from "non-serious memory error" is a problem. > > After fixing the strange repetition of same addresses (numerical address), > which seems to be a bug, or we can simply omit the repetition of the same numbers after a few times, > the dump will be very useful. This might be something that vgdb can do already. Run "valgrind --help" and search the output for 'vgdb'. The idea is to run valgrind with vgdb so that vgdb gets control at each valgrind error. Then a script tells vgdb what to do, which can include ordinary gdb commands such as "thread all tb" [or whatever the syntax is] to give a traceback for each thread. -- |