[Valgrind-users] SIGPIPE when using --track-origins
Hello all; I'm trying to analyze my application with the newly released Valgrind v3.9.0; for the most part it works greatly, but there is some crash happening when enabling the option track-origins. This is a desktop app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, FreeType, OpenGL and several multimedia libraries, among others. This is my valgrind command: $ valgrind \ --tool=memcheck \ --verbose \ --error-limit=no \ --suppressions=myapp.supp \ --log-file=valgrind-run.log \ --smc-check=all-non-file \ --leak-check=no \ --track-origins=yes \ ./myapp The reason for smc-check is that Qt uses JIT code for its QtScript and QML modules. leak-check is disables as a mean of limiting the scope of the test, and track-origins is what makes the command to fail (removing this option will correctly launch the app under Valgrind). This is what I get in the stdout: (myapp messages) Killed This is what I get in valgrind-run.log: (Lots of --3538-- Reading syms from file) (Lots of --3538-- REDIR: some address some symbol) ==3538== Process terminating with default action of signal 13 (SIGPIPE) ==3538==at 0x74FECCD: ??? (syscall-template.S:82) ==3538==by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9BD7: _IceWrite (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9CC3: IceFlush (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x654FB60: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6550698: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6563ADA: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6564618: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0xD7A9DFE: _SmcProcessMessage (in /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) ==3538==by 0xD9BDFD5: IceProcessMessages (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x719CD60: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) ==3538==by 0x71E91DD: QSocketNotifier::activated(int) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() Now it is obvious that the problem comes from the Kernel emiting the SIGPIPE signal, which afaik means that someone tried to write into a pipe for which nobody is listening on the other end. I'd like to ask you about some insight on what is being done when the track-origins option is enabled, and if this SIGPIPE is happening due to something done in either the Valgrind side or in my app side. Now, in trying the easy and ugly approach, I just tried to omit the SIGPIPE signal, by using this call in my app's initialization: signal(SIGPIPE, SIG_IGN); The results are that nothing interesting is written into the valgrind-run.log file, and this is what appears in the stdout: ICE default IO error handler doing an exit(), pid = 3538, errno = 32 In either case, the signal is emitted just before any text is shown on screen: the app has a splash screen showing some letters (in order to force the preload of all font related stuff). This splash screen appears, but without any contents, before the SIGPIPE comes into action. May this have anything to do with the problem? If you read up to here: thank you very much for your time :) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] SIGPIPE when using --track-origins
Does renaming the file ~/.ICEAuthority affect the problem? On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro oneorj...@gmail.com wrote: Hello all; I'm trying to analyze my application with the newly released Valgrind v3.9.0; for the most part it works greatly, but there is some crash happening when enabling the option track-origins. This is a desktop app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, FreeType, OpenGL and several multimedia libraries, among others. This is my valgrind command: $ valgrind \ --tool=memcheck \ --verbose \ --error-limit=no \ --suppressions=myapp.supp \ --log-file=valgrind-run.log \ --smc-check=all-non-file \ --leak-check=no \ --track-origins=yes \ ./myapp The reason for smc-check is that Qt uses JIT code for its QtScript and QML modules. leak-check is disables as a mean of limiting the scope of the test, and track-origins is what makes the command to fail (removing this option will correctly launch the app under Valgrind). This is what I get in the stdout: (myapp messages) Killed This is what I get in valgrind-run.log: (Lots of --3538-- Reading syms from file) (Lots of --3538-- REDIR: some address some symbol) ==3538== Process terminating with default action of signal 13 (SIGPIPE) ==3538==at 0x74FECCD: ??? (syscall-template.S:82) ==3538==by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9BD7: _IceWrite (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9CC3: IceFlush (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x654FB60: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6550698: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6563ADA: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6564618: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0xD7A9DFE: _SmcProcessMessage (in /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) ==3538==by 0xD9BDFD5: IceProcessMessages (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x719CD60: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) ==3538==by 0x71E91DD: QSocketNotifier::activated(int) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() Now it is obvious that the problem comes from the Kernel emiting the SIGPIPE signal, which afaik means that someone tried to write into a pipe for which nobody is listening on the other end. I'd like to ask you about some insight on what is being done when the track-origins option is enabled, and if this SIGPIPE is happening due to something done in either the Valgrind side or in my app side. Now, in trying the easy and ugly approach, I just tried to omit the SIGPIPE signal, by using this call in my app's initialization: signal(SIGPIPE, SIG_IGN); The results are that nothing interesting is written into the valgrind-run.log file, and this is what appears in the stdout: ICE default IO error handler doing an exit(), pid = 3538, errno = 32 In either case, the signal is emitted just before any text is shown on screen: the app has a splash screen showing some letters (in order to force the preload of all font related stuff). This splash screen appears, but without any contents, before the SIGPIPE comes into action. May this have anything to do with the problem? If you read up to here: thank you very much for your time :) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: ==15996== Possible data race during read of size 1 at 0x4DA7F90 by thread #1 ==15996== Locks held: none ==15996== at 0x4A08D79: my_memcmp (hg_intercepts.c:165) ==15996== by 0x4A0906F: pthread_mutex_destroy (hg_intercepts.c:473) snip ==15996== ==15996== This conflicts with a previous write of size 4 by thread #52 ==15996== Locks held: none ==15996== at 0x34EF80D5E2: __lll_unlock_wake (in /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A0E6: _L_unlock_766 (in /lib64/libpthread-2.5.so) ==15996== by 0x34EF80A04C: pthread_mutex_unlock (in /lib64/libpthread-2.5.so) ==15996== by 0x4A097E0: pthread_mutex_unlock (hg_intercepts.c:635) snip ==15996== ==15996== Address 0x4DA7F90 is 0 bytes inside a block of size 40 alloc'd ==15996== at 0x4A08BE5: operator new(unsigned long) (vg_replace_malloc.c:319) snip This was not a problem with 3.8.1 so appears to be a regression or new bug. saurabh -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
On Thursday 07 November 2013 16:22:56 Saurabh T wrote: Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: ==15996== Possible data race during read of size 1 at 0x4DA7F90 by thread #1 ==15996== Locks held: none ==15996==at 0x4A08D79: my_memcmp (hg_intercepts.c:165) ==15996==by 0x4A0906F: pthread_mutex_destroy (hg_intercepts.c:473) snip ==15996== ==15996== This conflicts with a previous write of size 4 by thread #52 ==15996== Locks held: none ==15996==at 0x34EF80D5E2: __lll_unlock_wake (in /lib64/libpthread-2.5.so) ==15996==by 0x34EF80A0E6: _L_unlock_766 (in /lib64/libpthread-2.5.so) ==15996==by 0x34EF80A04C: pthread_mutex_unlock (in /lib64/libpthread-2.5.so) ==15996==by 0x4A097E0: pthread_mutex_unlock (hg_intercepts.c:635) snip ==15996== ==15996== Address 0x4DA7F90 is 0 bytes inside a block of size 40 alloc'd ==15996==at 0x4A08BE5: operator new(unsigned long) (vg_replace_malloc.c:319) snip Can you prove that the destroy cannot happen during the unlock? This was not a problem with 3.8.1 so appears to be a regression or new bug. ... or a fix, which detects an actual problem in the code :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
From: fa...@kde.org To: valgrind-users@lists.sourceforge.net CC: saur...@hotmail.com Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy Date: Thu, 7 Nov 2013 17:25:57 +0100 On Thursday 07 November 2013 16:22:56 Saurabh T wrote: Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: snip Can you prove that the destroy cannot happen during the unlock? Not without code of course, but I dont believe it can. It can however happen *before* the unlock. I believe this is allowed by the standard? The code is something like this: Thread 1: locks deletes unlocks Thread 2: locks does_stuff unlocks saurabh This was not a problem with 3.8.1 so appears to be a regression or new bug. ... or a fix, which detects an actual problem in the code :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] SIGPIPE when using --track-origins
Yes, that did the trick! I had previously deleted that file, but restarting afterwards the PC, it gets recreated. If I try valgrind without the file existing, then the app initializes and runs. I guess this .ICEAuthority file gets regenerated every time the PC is rebooted; is there a way to permanently fix the issue? Actually, on the Qt side, this message appeared: Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed (which makes sense since the deleted file is what controls the session, but I don't really know the details about it). Is it, maybe, a bug in the way Qt handles the user session? On Thu, Nov 7, 2013 at 4:44 PM, Dan Kegel d...@kegel.com wrote: Does renaming the file ~/.ICEAuthority affect the problem? On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro oneorj...@gmail.com wrote: Hello all; I'm trying to analyze my application with the newly released Valgrind v3.9.0; for the most part it works greatly, but there is some crash happening when enabling the option track-origins. This is a desktop app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, FreeType, OpenGL and several multimedia libraries, among others. This is my valgrind command: $ valgrind \ --tool=memcheck \ --verbose \ --error-limit=no \ --suppressions=myapp.supp \ --log-file=valgrind-run.log \ --smc-check=all-non-file \ --leak-check=no \ --track-origins=yes \ ./myapp The reason for smc-check is that Qt uses JIT code for its QtScript and QML modules. leak-check is disables as a mean of limiting the scope of the test, and track-origins is what makes the command to fail (removing this option will correctly launch the app under Valgrind). This is what I get in the stdout: (myapp messages) Killed This is what I get in valgrind-run.log: (Lots of --3538-- Reading syms from file) (Lots of --3538-- REDIR: some address some symbol) ==3538== Process terminating with default action of signal 13 (SIGPIPE) ==3538==at 0x74FECCD: ??? (syscall-template.S:82) ==3538==by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9BD7: _IceWrite (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9CC3: IceFlush (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x654FB60: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6550698: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6563ADA: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6564618: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0xD7A9DFE: _SmcProcessMessage (in /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) ==3538==by 0xD9BDFD5: IceProcessMessages (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x719CD60: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) ==3538==by 0x71E91DD: QSocketNotifier::activated(int) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() Now it is obvious that the problem comes from the Kernel emiting the SIGPIPE signal, which afaik means that someone tried to write into a pipe for which nobody is listening on the other end. I'd like to ask you about some insight on what is being done when the track-origins option is enabled, and if this SIGPIPE is happening due to something done in either the Valgrind side or in my app side. Now, in trying the easy and ugly approach, I just tried to omit the SIGPIPE signal, by using this call in my app's initialization: signal(SIGPIPE, SIG_IGN); The results are that nothing interesting is written into the valgrind-run.log file, and this is what appears in the stdout: ICE default IO error handler doing an exit(), pid = 3538, errno = 32 In either case, the signal is emitted just before any text is shown on screen: the app has a splash screen showing some letters (in order to force the preload of all font related stuff). This splash screen appears, but without any contents, before the SIGPIPE comes into action. May this have anything to do with the problem? If you read up to here: thank you very much for your time :) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___
Re: [Valgrind-users] SIGPIPE when using --track-origins
I found the trick by googling the error message you found after ignoring sigpipe, ICE default IO error handler. There are lots of people complaining about it, and removing .ICEAuthority was listed as a workaround. I have no idea what the cause is. It might help if you could create a minimal test case and file a bug showing how to reproduce the problem from source. Filing against valgrind would be wrong but might be a good enough place to start. On Thu, Nov 7, 2013 at 9:47 AM, Juan Navarro oneorj...@gmail.com wrote: Yes, that did the trick! I had previously deleted that file, but restarting afterwards the PC, it gets recreated. If I try valgrind without the file existing, then the app initializes and runs. I guess this .ICEAuthority file gets regenerated every time the PC is rebooted; is there a way to permanently fix the issue? Actually, on the Qt side, this message appeared: Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed (which makes sense since the deleted file is what controls the session, but I don't really know the details about it). Is it, maybe, a bug in the way Qt handles the user session? On Thu, Nov 7, 2013 at 4:44 PM, Dan Kegel d...@kegel.com wrote: Does renaming the file ~/.ICEAuthority affect the problem? On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro oneorj...@gmail.com wrote: Hello all; I'm trying to analyze my application with the newly released Valgrind v3.9.0; for the most part it works greatly, but there is some crash happening when enabling the option track-origins. This is a desktop app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, FreeType, OpenGL and several multimedia libraries, among others. This is my valgrind command: $ valgrind \ --tool=memcheck \ --verbose \ --error-limit=no \ --suppressions=myapp.supp \ --log-file=valgrind-run.log \ --smc-check=all-non-file \ --leak-check=no \ --track-origins=yes \ ./myapp The reason for smc-check is that Qt uses JIT code for its QtScript and QML modules. leak-check is disables as a mean of limiting the scope of the test, and track-origins is what makes the command to fail (removing this option will correctly launch the app under Valgrind). This is what I get in the stdout: (myapp messages) Killed This is what I get in valgrind-run.log: (Lots of --3538-- Reading syms from file) (Lots of --3538-- REDIR: some address some symbol) ==3538== Process terminating with default action of signal 13 (SIGPIPE) ==3538==at 0x74FECCD: ??? (syscall-template.S:82) ==3538==by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9BD7: _IceWrite (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9CC3: IceFlush (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x654FB60: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6550698: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6563ADA: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6564618: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0xD7A9DFE: _SmcProcessMessage (in /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) ==3538==by 0xD9BDFD5: IceProcessMessages (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x719CD60: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) ==3538==by 0x71E91DD: QSocketNotifier::activated(int) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() Now it is obvious that the problem comes from the Kernel emiting the SIGPIPE signal, which afaik means that someone tried to write into a pipe for which nobody is listening on the other end. I'd like to ask you about some insight on what is being done when the track-origins option is enabled, and if this SIGPIPE is happening due to something done in either the Valgrind side or in my app side. Now, in trying the easy and ugly approach, I just tried to omit the SIGPIPE signal, by using this call in my app's initialization: signal(SIGPIPE, SIG_IGN); The results are that nothing interesting is written into the valgrind-run.log file, and this is what appears in the stdout: ICE default IO error handler doing an exit(), pid = 3538, errno = 32 In either case, the signal is emitted just before any text is shown on screen: the app has a splash screen showing some letters (in order to force the preload of all font related stuff). This splash screen appears, but without any contents, before the SIGPIPE comes into action. May this have anything to do with the problem? If you read up to
Re: [Valgrind-users] SIGPIPE when using --track-origins
Yes, the thing is I looked for that error message, and deleted the file as suggested in other forums, but after that my machine had to be rebooted and I didn't realize that this file had reappeared... too bad! I'll try to create a test case and will file a report against the corresponding tracker. Thanks for the help On Thu, Nov 7, 2013 at 6:59 PM, Dan Kegel d...@kegel.com wrote: I found the trick by googling the error message you found after ignoring sigpipe, ICE default IO error handler. There are lots of people complaining about it, and removing .ICEAuthority was listed as a workaround. I have no idea what the cause is. It might help if you could create a minimal test case and file a bug showing how to reproduce the problem from source. Filing against valgrind would be wrong but might be a good enough place to start. On Thu, Nov 7, 2013 at 9:47 AM, Juan Navarro oneorj...@gmail.com wrote: Yes, that did the trick! I had previously deleted that file, but restarting afterwards the PC, it gets recreated. If I try valgrind without the file existing, then the app initializes and runs. I guess this .ICEAuthority file gets regenerated every time the PC is rebooted; is there a way to permanently fix the issue? Actually, on the Qt side, this message appeared: Qt: Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed (which makes sense since the deleted file is what controls the session, but I don't really know the details about it). Is it, maybe, a bug in the way Qt handles the user session? On Thu, Nov 7, 2013 at 4:44 PM, Dan Kegel d...@kegel.com wrote: Does renaming the file ~/.ICEAuthority affect the problem? On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro oneorj...@gmail.com wrote: Hello all; I'm trying to analyze my application with the newly released Valgrind v3.9.0; for the most part it works greatly, but there is some crash happening when enabling the option track-origins. This is a desktop app compiled under GCC 4.6, which makes heavy use of Qt (4.8) + QML, FreeType, OpenGL and several multimedia libraries, among others. This is my valgrind command: $ valgrind \ --tool=memcheck \ --verbose \ --error-limit=no \ --suppressions=myapp.supp \ --log-file=valgrind-run.log \ --smc-check=all-non-file \ --leak-check=no \ --track-origins=yes \ ./myapp The reason for smc-check is that Qt uses JIT code for its QtScript and QML modules. leak-check is disables as a mean of limiting the scope of the test, and track-origins is what makes the command to fail (removing this option will correctly launch the app under Valgrind). This is what I get in the stdout: (myapp messages) Killed This is what I get in valgrind-run.log: (Lots of --3538-- Reading syms from file) (Lots of --3538-- REDIR: some address some symbol) ==3538== Process terminating with default action of signal 13 (SIGPIPE) ==3538==at 0x74FECCD: ??? (syscall-template.S:82) ==3538==by 0xD9B4D0E: ??? (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9BD7: _IceWrite (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0xD9B9CC3: IceFlush (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x654FB60: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6550698: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6563ADA: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0x6564618: ??? (in /opt/Qt-4.8.4-release/lib/libQtGui.so.4.8.4) ==3538==by 0xD7A9DFE: _SmcProcessMessage (in /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1) ==3538==by 0xD9BDFD5: IceProcessMessages (in /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0) ==3538==by 0x719CD60: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) ==3538==by 0x71E91DD: QSocketNotifier::activated(int) (in /opt/Qt-4.8.4-release/lib/libQtCore.so.4.8.4) --3538-- Discarding syms at 0x153e95d0-0x153eafa8 in /usr/lib/x86_64-linux-gnu/gconv/UTF-16.so due to munmap() Now it is obvious that the problem comes from the Kernel emiting the SIGPIPE signal, which afaik means that someone tried to write into a pipe for which nobody is listening on the other end. I'd like to ask you about some insight on what is being done when the track-origins option is enabled, and if this SIGPIPE is happening due to something done in either the Valgrind side or in my app side. Now, in trying the easy and ugly approach, I just tried to omit the SIGPIPE signal, by using this call in my app's initialization: signal(SIGPIPE, SIG_IGN); The results are that nothing interesting is written into the valgrind-run.log file, and this is what appears in the stdout: ICE default IO error handler
Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy
On 7 November 2013 18:21, Saurabh T saur...@hotmail.com wrote: From: fa...@kde.org To: valgrind-users@lists.sourceforge.net CC: saur...@hotmail.com Subject: Re: [Valgrind-users] Helgrind 3.9.0: false positive with pthread_mutex_destroy Date: Thu, 7 Nov 2013 17:25:57 +0100 On Thursday 07 November 2013 16:22:56 Saurabh T wrote: Helgrind seems to be reporting false positive data race when pthread_mutex_destroy is called in a different thread from pthread_mutex_unlock. Unfortunately I cannot make a test case, sorry. But here's the relevant output: snip Can you prove that the destroy cannot happen during the unlock? Not without code of course, but I dont believe it can. It can however happen *before* the unlock. I believe this is allowed by the standard? The code is something like this: Thread 1: locks deletes unlocks Thread 2: locks does_stuff unlocks saurabh That is most definitely wrong. Thread 1 destroys a locked mutex, and according to http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_init.html : Attempting to destroy a locked mutex results in undefined behavior. BR Magnus Reftel -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
