Greetz,
Using C++, Qt 4.7, openSUSE 11.4, Valgrind, GCC
Actually this application runs very fine on Linux, but crashes on
Windows if I move the mouse wheel.
I have NOT written any event for wheel handling in the code.
So, I was thinking that I should dig in the memory leaks etc, and now
I don't
On 05/12/12 09:08, Anisha Kaul wrote:
The problem is that the functions pointed out by Valgrind are NO where
in my code. I haven't used functions like - `createObject`,
`setContent` etc. anywhere. They look like internal Qt functions.
You need to use --num-callers to ask for deeper stack
On Wednesday, December 05, 2012, Wiser, Tyson wrote:
Valgrind shows tons of errors pointing to Qt's source files, but not to my
source files! Please explain what to make out of this.
I don't use QT, but I've noticed similar behavior when I have a statically
linked application (tons of errors
Hi Guys,
I am trying to track a memory leak in a vmware service and I tried to use
valgrind to track the leak. Unfortunately it is stopping for the following
instruction.
vex x86-IR: unhandled instruction bytes: 0xF 0xB 0xFF 0x85
I am using a busybox 1.20.0. Help would be highly appreciated.
It would be better to use atomics (with proper memory order), which can
solve this kind of problem without unintended consequences. As mentioned
before, this still may not be as maintenance friendly as locking, but at
least it will be correct.
Brian
On Wed, Dec 5, 2012 at 9:29 AM, Julian
Here are the threads I have:
{
pthread_rwlock_rdlock();
x = 1;
pthread_rwlock_rdunlock();
}
{
pthread_rwlock_wrlock();
if (x) {
x = 0;
} else {
foo();
}
pthread_rwlock_wrunlock();
}
Boehm's paper did not convince me of a bug.
Since pthread locks will include proper
On 12/05/2012 09:18 AM, Simon Bonello wrote:
I am trying to track a memory leak in a vmware service and I tried to use
valgrind to track the leak. Unfortunately it is stopping for the following
instruction.
vex x86-IR:unhandled instruction bytes:0xF 0xB 0xFF 0x85
I am using a busybox
On Wednesday, December 05, 2012, Leif Walsh wrote:
Here are the threads I have:
{
pthread_rwlock_rdlock();
x = 1;
pthread_rwlock_rdunlock();
}
{
pthread_rwlock_wrlock();
if (x) {
x = 0;
} else {
foo();
}
pthread_rwlock_wrunlock();
}
Boehm's paper did
On Wed, 2012-12-05 at 11:57 -0800, John Reiser wrote:
On 12/05/2012 09:18 AM, Simon Bonello wrote:
I am trying to track a memory leak in a vmware service and I tried to use
valgrind to track the leak. Unfortunately it is stopping for the following
instruction.
vex x86-IR:unhandled
learning why Helgrind works the way it does currently, i.e., why did
it abandon Eraser-style locksets [2] in recent versions?
With Memcheck, great efforts were made, and continue to be made, to have
a very low -- essentially zero -- false error rate. Feedback from users
showed that to be
Sent from my iPhone
On Dec 5, 2012, at 15:38, Julian Seward jsew...@acm.org wrote:
On Wednesday, December 05, 2012, Leif Walsh wrote:
Here are the threads I have:
{
pthread_rwlock_rdlock();
x = 1;
pthread_rwlock_rdunlock();
}
{
pthread_rwlock_wrlock();
if (x) {
x = 0;
On Wednesday 05 December 2012 16:39:47 Leif Walsh wrote:
The important synchronization point isn't the rdunlock, it's the wrlock.
Well, you need two locks, for a happens-before relationship to be established.
If you remove the rdlock/rdunlock completely (since it could basically be a
no-op for
Rdunlock happens before wrlock.
Sent from my iPhone
On Dec 5, 2012, at 16:51, David Faure fa...@kde.org wrote:
On Wednesday 05 December 2012 16:39:47 Leif Walsh wrote:
The important synchronization point isn't the rdunlock, it's the wrlock.
Well, you need two locks, for a happens-before
Sent from my iPhone
On Dec 5, 2012, at 16:31, Patrick J. LoPresti lopre...@gmail.com wrote:
On Wed, Dec 5, 2012 at 10:29 AM, Leif Walsh leif.wa...@gmail.com wrote:
Here are the threads I have:
{
pthread_rwlock_rdlock();
x = 1;
pthread_rwlock_rdunlock();
}
{
On Wednesday 05 December 2012 16:52:42 Leif Walsh wrote:
Rdunlock happens before wrlock.
... and is supposed to be about reading only, so why would CPUs bother to
propagate modified data inside that lock, to other CPUs?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE,
15 matches
Mail list logo
