I just received a valgrind log from a user which runs application on a bleeding edge and the log is full of: ==13145== Invalid write of size 4 ==13145== at 0x723CB3D: _cairo_xlib_source_create_for_pattern (cairo-xlib-source.c:955) ==13145== by 0x1CFFF: ??? ==13145== Address 0xbee4a12c is on thread 1's stack ==13145== ==13145== Invalid write of size 4 ==13145== at 0x723CB47: _cairo_xlib_source_create_for_pattern (cairo-xlib-source.c:955) ==13145== by 0x1CFFF: ??? ==13145== Address 0xbee4a130 is on thread 1's stack ==13145== ==13145== Invalid write of size 4 ==13145== at 0x723CB51: _cairo_xlib_source_create_for_pattern (cairo-xlib-source.c:955) ==13145== by 0x1CFFF: ??? ==13145== Address 0xbee4a134 is on thread 1's stack where valgrind gave up finally and wrote a nice message which I never saw yet: ==13145== More than 1000 different errors detected. I'm not reporting any more. ==13145== Final error counts will be inaccurate. Go fix your program! ==13145== Rerun with --error-limit=no to disable this cutoff. Note ==13145== that errors may occur in your program without prior warning from ==13145== Valgrind, because errors are no longer being displayed.
Line 955 of that file in cairo 1.12.2 is: local_pattern.base.matrix = pattern->base.matrix; That's just a struct-copy to a local/automatic variable. There is not much chance for this being any kind of wrong. http://cgit.freedesktop.org/cairo/tree/src/cairo-xlib-source.c?id=dbc0efad7e565558a3abf7f69d7675efddc4688d#n955 What's the full command line that was used? Any "magic" flags for valgrind? This is valgrind's memcheck, isn't it? How does valgrind's output begin (I assume that your snippet is from somewhere near the end of the log)? How was cairo built (was support for special-valgrind/memcheck-magic enabled)? I asked on FreeNode/#valgrind-dev and it looks like this kind of message could be caused by marking part of the stack as NOACCESS via VALGRIND_MAKE_MEM_NOACCESS. Were any patches applied to cairo?
Don't worry about it, this is just self-inflicted harm - we mark part of the stack as invalid access, and try to reuse it. The *_fini() are a little overzealous.
You are right, this is from the end of valgrind, memcheck tool. I do not think this is compiled with any special patches on cairo, just vanilla checkout of it. The valgrind command looked like this: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt The log starts: ==13145== Memcheck, a memory error detector ==13145== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==13145== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==13145== Command: evolution ==13145== --13145-- WARNING: Serious error when reading debug info --13145-- When reading debug info from /usr/lib/libGL.so.195.36.24: --13145-- Can't make sense of .data section mapping --13145-- WARNING: Serious error when reading debug info --13145-- When reading debug info from /usr/lib/libGLcore.so.195.36.24: --13145-- Can't make sense of .data section mapping then few runtime warnings, which are from evolution and unrelated, then the cairo issues start: ==13145== Invalid write of size 4 ==13145== at 0x723CAF5: _cairo_xlib_source_create_for_pattern (cairo-xlib-source.c:955) ==13145== Address 0xbee4d4e0 is on thread 1's stack ==13145== ==13145== Invalid write of size 4 ==13145== at 0x723CB01: _cairo_xlib_source_create_for_pattern (cairo-xlib-source.c:955) ==13145== Address 0xbee4d4e4 is on thread 1's stack ==13145== (In reply to comment #2) > Don't worry about it, this is just self-inflicted harm - we mark part of the > stack as invalid access, and try to reuse it. The *_fini() are a little > overzealous. I'm sorry, I do not follow. If that's for me, to "not worry", then the main point of this bug report is that these errors make it impossible to track memory issues with valgrind, because of cairo. And cairo is used in quite many projects these days (basically anything using gtk).
Created attachment 64942 [details] full log, as sent by the user
*** Bug 75896 has been marked as a duplicate of this bug. ***
Created attachment 116189 [details] [review] Avoid indiscriminate use of VALGRIND_MAKE_MEM_NOACCESS Please fix this, the false positives are distracting when using Valgrind to find real errors. Attached is one possible fix.
Thanks, applied and pushed: 1bcce43..bb24f16 master -> master
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.