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 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=60136231&iu=/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=60136231&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
