https://bugs.kde.org/show_bug.cgi?id=392855
--- Comment #11 from Tom Hughes <t...@compton.nu> --- For the record here is the backtrace for the 1024 byte malloc: #0 __GI___libc_malloc (bytes=1024) at malloc.c:3012 #1 0x00007ffff7e2e8f0 in __GI__IO_file_doallocate (fp=0x7ffff7f7e780 <_IO_2_1_stdout_>) at filedoalloc.c:101 #2 0x00007ffff7e3ccd0 in __GI__IO_doallocbuf (fp=fp@entry=0x7ffff7f7e780 <_IO_2_1_stdout_>) at libioP.h:839 #3 0x00007ffff7e3bf58 in _IO_new_file_overflow (f=0x7ffff7f7e780 <_IO_2_1_stdout_>, ch=-1) at fileops.c:752 #4 0x00007ffff7e3b05f in _IO_new_file_xsputn (f=0x7ffff7f7e780 <_IO_2_1_stdout_>, data=<optimized out>, n=3) at libioP.h:839 #5 0x00007ffff7e0e345 in _IO_vfprintf_internal (s=0x7ffff7f7e780 <_IO_2_1_stdout_>, format=0x402010 "a: %d\n", ap=ap@entry=0x7fffffffcc80) at ../libio/libioP.h:839 #6 0x00007ffff7e1715a in __printf (format=<optimized out>) Which, as expected, is glibc allocating a I/O buffer for the stdout stream. If you unbuffer that stream before the print with: setvbuf(stdout, NULL, _IONBF, 0); then it goes away. Maybe previously the stdout stream had it's buffer allocated during startup and valgrind didn't notice it and now it's done on demand when stdout is first used? You would still have seen the same effect for any other file you opened though. -- You are receiving this mail because: You are watching all bug changes.
