[Qt-interest] QTimer and crashing...

[BRM]

----- Original Message ----

> Brad Howes wrote:
>  > On Aug 3, 2010, at 9:36 PM, william.crocker at analog.com wrote:
>  >> Can you say, "valgrind"?
>  >  Why?
> Quoth the OP
>     On one instance (and only one  instance out of dozens of
>     crashes) GDB reported a memory  corruption error.
> Endth quote.
> Since there is memory corruption  and the OP appears to be
> using a POSIX-compatible OS, then valgrind is  the
> obvious choice.
> Valgrind will report invalid memory access before  it can cause
> the program to crash. The latest versions will report  when
> initialised data is accessed at all, older version only
> tracked  uninitialised data and reported when the data was used
> for flow-control or  I/O.

Well, I've tried valgrind on this particular application in the past, and it 
just doesn't work. The whole application grinds to a halt under the resources 
consumed.
So unfortunately that's out of the question.

That said, I've also looked at electronic fence (efence), but that ends up 
giving a seg fault on a connect() statement, getting no where near the actual 
issue.

I have been doing some further testing[1], and I think the QTimer was part of 
the problem, but not necessarily the whole problem. I haven't found the other 
side of the issue yet.
My initial point of this thread was to try to figure out if using QTimer inside 
of a QTcpSocket derived class like that was something that I should expect to 
work,
or something that is way-out-there never-do-that kind of thing.

TIA,

Ben

[1] One test removed the QTimer uses like that from all sides, but the issue 
still failed. Though I was able to determine that memory growth is another 
symptom too. My hypothesis for that test was the QTimers were helping to back 
stuff up, helping to cause the memory growth. However, that proved somewhat 
false; but they are somehow contributing.