Re: [Valgrind-users] SIGPIPE when using "--track-origins"

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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 <da...@ke...> wrote:
> Does renaming the file  ~/.ICEAuthority affect the problem?
>
> On Thu, Nov 7, 2013 at 7:05 AM, Juan Navarro <one...@gm...> 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
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users