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

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

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 <da...@ke...> 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 <one...@gm...> 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 <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