https://bugs.kde.org/show_bug.cgi?id=359950
--- Comment #6 from Tom Hughes ---
Note that I didn't mean spills/reloads that valgrind's internal implementation
does, but rather any spills/reloads that the original compiler generated.
My understanding was that those would use the normal memory loca
https://bugs.kde.org/show_bug.cgi?id=365258
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=365258
Tom Hughes changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=371471
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #2 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=371471
--- Comment #3 from Tom Hughes ---
Also that code doesn't even compile:
bericote [/tmp] % g++ -std=c++14 -o x x.cpp
x.cpp: In function ‘int main()’:
x.cpp:12:17: error: no matching function for call to ‘operator new(sizetype,
A*&)’
new (obj) A(20);
https://bugs.kde.org/show_bug.cgi?id=371471
--- Comment #4 from Tom Hughes ---
I'm pretty sure it's not the same anyway as the other bug is about static
objects, and there are none here. This is almost certainly something different
- the fact that it is reporting two allocations suggests that it
https://bugs.kde.org/show_bug.cgi?id=371471
Tom Hughes changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=368507
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=368791
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=368873
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=360188
Tom Hughes changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=355803
--- Comment #4 from Tom Hughes ---
Note that in general patches will be reviewed when we have a release upcoming,
so don't worry if it sits around for a while.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=355803
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #3 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=357035
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=357035
Tom Hughes changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=92036
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #3 from Tom Hughes ---
https://bugs.kde.org/show_bug.cgi?id=345414
Tom Hughes changed:
What|Removed |Added
CC||jb.1234a...@gmail.com
--- Comment #7 from Tom Hugh
https://bugs.kde.org/show_bug.cgi?id=357781
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=357833
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=357928
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=357928
Tom Hughes changed:
What|Removed |Added
Summary|Thread 1: status = |valgrind:
|VgTs_Runnable
https://bugs.kde.org/show_bug.cgi?id=357928
--- Comment #3 from Tom Hughes ---
So there are no other valgrind messages before that one?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=362223
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #2 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=362223
--- Comment #6 from Tom Hughes ---
Well 4K seems extremely large, but it seems the real problem is that your
.valgrindrc is a directory:
read(3, 0x802001230, 4096) = -1 EISDIR (Is a directory)
It is supposed to be a file...
--
You are r
https://bugs.kde.org/show_bug.cgi?id=362223
--- Comment #8 from Tom Hughes ---
Well it's a bug that valgrind crashes when .valgrindrc is a folder, but the
easy workaround is for you to remove that folder (it serves no purpose -
firstly because .valgrindrc is optional and secondly because it shoul
https://bugs.kde.org/show_bug.cgi?id=362223
--- Comment #10 from Tom Hughes ---
Please use the mailing lists for general questions - it's not really
appropriate for the bug tracker. See
http://valgrind.org/support/mailing_lists.html for more information.
--
You are receiving this mail because:
https://bugs.kde.org/show_bug.cgi?id=362276
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #4 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=362276
Tom Hughes changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=357338
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Summary|Unhandled instr
https://bugs.kde.org/show_bug.cgi?id=358620
--- Comment #1 from Tom Hughes ---
This is epoll_create1.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=358620
Tom Hughes changed:
What|Removed |Added
Summary|WARNING: unhandled syscall: |ARM: unhandled syscall: 357
|357
https://bugs.kde.org/show_bug.cgi?id=303877
--- Comment #15 from Tom Hughes ---
It's highly unlikely that there will be any quick progress, because any fix
would be require valgrind to be able to decompress zlib compressed data but
valgrind is not able to link to libraries so we can't just use zl
https://bugs.kde.org/show_bug.cgi?id=303877
--- Comment #17 from Tom Hughes ---
That's certainly useful to know about - it even has an "inflate only" version.
It will still need some patching to stop it use memcpy/memset etc.
--
You are receiving this mail because:
You are watching all bug cha
https://bugs.kde.org/show_bug.cgi?id=253451
Bug 253451 depends on bug 212352, which changed state.
Bug 212352 Summary: vex amd64 unhandled opc_aux = 0x 2, first_opcode == 0xDC
(FCOM)
https://bugs.kde.org/show_bug.cgi?id=212352
What|Removed |Added
--
https://bugs.kde.org/show_bug.cgi?id=212352
Tom Hughes changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=212352
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #2 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=358988
Tom Hughes changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=353370
Tom Hughes changed:
What|Removed |Added
CC||brat...@opera.com
--- Comment #13 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=361810
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #4 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=361810
--- Comment #5 from Tom Hughes ---
Ah, if you add the childs you will see each one do:
3992 lseek(0, -8, SEEK_CUR)= 4
for some reason...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=361810
--- Comment #7 from Tom Hughes ---
I think the problem is that __libc_freeres calls (among many other things) the
_IO_unbuffer_write to free the buffers for stdio streams.
That "unbuffers" each file by calling _IO_SETBUF (fp, NULL, 0) to drop the
buffe
https://bugs.kde.org/show_bug.cgi?id=361810
--- Comment #8 from Tom Hughes ---
Of course the buffer isn't really shared (this is fork, not threads...) but the
file position is.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=361810
--- Comment #6 from Tom Hughes ---
It's something in glibc doing it when __libc_freeres is run as the child exits.
If you add run-libc-freeres=no to the valgrind options then it doesn't
happen.
--
You are receiving this mail because:
You are watc
https://bugs.kde.org/show_bug.cgi?id=361810
--- Comment #10 from Tom Hughes ---
The call to __libc_freeres is not normally made at all - it is forced by
valgrind (unless you use that switch) so that people won't moan about "still
reachable" blocks of memory in the leak report due to glibc still h
https://bugs.kde.org/show_bug.cgi?id=361810
--- Comment #11 from Tom Hughes ---
See http://valgrind.org/docs/manual/faq.html#faq.exit_errors for more
information.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=361810
--- Comment #13 from Tom Hughes ---
I'm pretty sure that it's a bug in glibc that should be fixed anyway - you're
only supposed to call __libc_freeres when the process is exiting and in that
case there shouldn't be any need to rewind any descriptor if y
https://bugs.kde.org/show_bug.cgi?id=359503
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #3 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=359705
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes --
https://bugs.kde.org/show_bug.cgi?id=359705
--- Comment #3 from Tom Hughes ---
What you're missing is that valgrind imposes it's own limit of 8Mb on the
stack, which you have clearly hit given the size it reported. Just looking at
the memory map won't help you.
--
You are receiving this mail be
https://bugs.kde.org/show_bug.cgi?id=359705
--- Comment #4 from Tom Hughes ---
At least I thought it did, because I remember it being discussed recently, bit
I can't find it right now...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=359950
Tom Hughes changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=359950
--- Comment #3 from Tom Hughes ---
Although I'm not clear if that is what has happened here (and this should only
happen when not running under valgrind) that's not actually true with x87
because if the compiler chooses to move one of the values from th
52 matches
Mail list logo
