|
From: Milian W. <ma...@mi...> - 2010-07-31 14:44:21
|
Hey all, in KDevelop 4 I have this reproducible issue: ==16813== Syscall param utimes(tvp[1]) points to uninitialised byte(s) ==16813== at 0xAA898D7: utimes (in /lib/libc-2.12.so) ==16813== by 0x3072446E: CppTools::FileModificationTimeWrapper::FileModificationTimeWrapper(QStringLi st const&, QString const&) (includepathresolver.cpp:124) ==16813== by 0x30722394: CppTools::IncludePathResolver::resolveIncludePathInternal(QString const&, QString const&, QString const&, CppTools::SourcePathInformation const&, int) (includepathresolver.cpp:712) ==16813== by 0x30721EBA: CppTools::IncludePathResolver::resolveIncludePath(QString const&, QString const&, int) (includepathresolver.cpp:660) ==16813== by 0x3072044A: CppTools::IncludePathResolver::resolveIncludePath(QString const&) (includepathresolver.cpp:443) ==16813== by 0x30701C08: IncludePathComputer::computeBackground() (includepathcomputer.cpp:184) ==16813== by 0x307063F5: CPPParseJob::includePaths() const (cppparsejob.cpp:256) ==16813== by 0x30705DC4: CPPParseJob::mergeDefines(CppPreprocessEnvironment&) const (cppparsejob.cpp:210) ==16813== by 0x30714438: PreprocessJob::run() (preprocessjob.cpp:157) ==16813== by 0x65B3B44: ??? (in /usr/lib/libthreadweaver.so.4.5.0) ==16813== by 0x65B3C7D: ThreadWeaver::Job::execute(ThreadWeaver::Thread*) (in /usr/lib/libthreadweaver.so.4.5.0) ==16813== by 0x65B4E42: ??? (in /usr/lib/libthreadweaver.so.4.5.0) ==16813== Address 0x346a9da0 is on thread 13's stack ==16813== Uninitialised value was created by a stack allocation ==16813== at 0x3072228F: CppTools::IncludePathResolver::resolveIncludePathInternal(QString const&, QString const&, QString const&, CppTools::SourcePathInformation const&, int) (includepathresolver.cpp:699) The code for it looks like this: http://gitorious.org/kdevelop/kdevelop/blobs/master/languages/cpp/incl udepathresolver.cpp or here the code before the warning: QByteArray bFileName = filename.toLocal8Bit(); const char* bFileNameC = bFileName.constData(); struct stat s; if( stat( bFileNameC, &s ) == 0 ) { ///Success m_stat[filename] = s.st_mtime; ///change the modification-time to m_newTime struct timeval times[2]; times[0].tv_sec = m_newTime; times[0].tv_usec = 0; times[1].tv_sec = m_newTime; times[1].tv_usec = 0; if( utimes( bFileNameC, times ) != 0 ) { ifTest( cout << "failed to touch " << it->toUtf8().constData() << endl ); } } To me this looks just fine and I don't get what could be unitializsed in the "stack allocation" in loc 699... Is this a false-positive? Or is stat / utimes really wrong here? Note that we haven't had any problems so far (at least none from which we know). Bye -- Milian Wolff ma...@mi... http://milianw.de |
|
From: John R. <jr...@bi...> - 2010-08-01 17:33:03
|
> http://gitorious.org/kdevelop/kdevelop/blobs/master/languages/cpp/includepathresolver.cpp I agree that the code at line 90: explicit FileModificationTimeWrapper( const QStringList& files = QStringList(), const QString& workingDirectory = QString() ) : m_newTime( time(0) ) does seem to initialize m_newTime, and therefore the code from line 119: times[0].tv_sec = m_newTime; times[0].tv_usec = 0; times[1].tv_sec = m_newTime; times[1].tv_usec = 0; would initialize all of the array times[2], and thus the complaint by memcheck about times() on line 124 would indicate some problem with memcheck's understanding of utimes(), or a compiler problem with the initialization of m_newTime. What is the shortest source-code test case that reproduces this problem? -- |
|
From: Milian W. <ma...@mi...> - 2010-08-06 10:47:05
|
On Sunday, 1. August 2010 19:32:34 John Reiser wrote: > > http://gitorious.org/kdevelop/kdevelop/blobs/master/languages/cpp/include > > pathresolver.cpp > > I agree that the code at line 90: > explicit FileModificationTimeWrapper( const QStringList& files = > QStringList(), const QString& workingDirectory = QString() ) : m_newTime( > time(0) ) does seem to initialize m_newTime, and therefore the code from > line 119: times[0].tv_sec = m_newTime; > times[0].tv_usec = 0; > times[1].tv_sec = m_newTime; > times[1].tv_usec = 0; > would initialize all of the array times[2], and thus the complaint by > memcheck about times() on line 124 would indicate some problem with > memcheck's understanding of utimes(), or a compiler problem with the > initialization of m_newTime. > > What is the shortest source-code test case that reproduces this problem? I don't get it... this code doesn't show any problems in valgrind for me: http://mwolff.pastebin.com/JxCgvtK9 :( -- Milian Wolff ma...@mi... http://milianw.de |
|
From: John R. <jr...@bi...> - 2010-08-06 22:10:29
|
>> What is the shortest source-code test case that reproduces this problem? > I don't get it... this code doesn't show any problems in valgrind for me: > > http://mwolff.pastebin.com/JxCgvtK9 The short test case shows that memcheck "knows" about utimes(). Suspicion now turns to the compiler/linker. I see that the original code has an 'explicit' keyword but the short test case does not. If memcheck still does not complain after enlarging the short test case to contain 'explicit', then there must be some other differences. Finding them may require disassembling the generated code and/or single-stepping the execution. -- |
|
From: Milian W. <ma...@mi...> - 2010-08-06 22:32:38
|
On Saturday 07 August 2010 00:10:02 John Reiser wrote: > >> What is the shortest source-code test case that reproduces this problem? > > > > I don't get it... this code doesn't show any problems in valgrind for me: > > > > http://mwolff.pastebin.com/JxCgvtK9 > > The short test case shows that memcheck "knows" about utimes(). Suspicion > now turns to the compiler/linker. I see that the original code has an > 'explicit' keyword but the short test case does not. If memcheck still > does not complain after enlarging the short test case to contain > 'explicit', then there must be some other differences. Finding them may > require disassembling the generated code and/or single-stepping the > execution. Even with explicit, I don't get anything from valgrind. Compiling with g++ -g -O0 should be enough, right? Anyhow, since I never did any disassembling and that error is not really causing any problems for us, I'll just ignore it for now :) I hoped someone would see a glaring error or something, well thanks anyways. Bye -- Milian Wolff ma...@mi... http://milianw.de |
|
From: Peyush K. <pey...@ho...> - 2010-08-07 08:29:58
|
Hi all, how can i supress errors orinigination from /lib/libc-2.5.so (the stack shows *below main*) I am seeing this on RHEL 5.1 linux platform Regards, Peyush. |