#11 if(!$cursor->isActive()) crashes

[Michael Traxler]

Hi,

this is a more severe problem, of PertQt or puic, I
don't know.
Whenever you use a DataTable the puic generates the
following code:
sub polish
{
if(DataTable2)
{
my $cursor = DataTable2->sqlCursor();

if(!$cursor)
{
$cursor = Qt::SqlCursor("Art", 1,
praxis_conConnection);
DataTable2->setSqlCursor($cursor, 0, 1);

}
if(!$cursor->isActive())
{

DataTable2->refresh(&Qt::DataTable::RefreshAll);
}
}
this->SUPER::polish();
}
----------
The strange thing is, that it sometimes work...
But very often the application crashes (SIGSEGV) at
$cursor->isActive().
If you just remove the whole if-statement, everything
works quite OK. (I think the qt-DataTable is not flawless).

example attached...

I'm using qt-3.0.5 and newest cvs version. Database
mysql 3.23.48-log

Michael

[Michael Traxler]

sample database access

[germain garand]

Logged In: YES
user_id=145773

Could you try to change the this->SUPER::polish() statement
to the new syntax SUPER->polish() and tell me if it helps ?

(I'll try to test it myself later, but I need to adapt your
example to my test DB first)

[Michael Traxler]

Logged In: YES
user_id=623079

Hi Germain,

Yes, that's it! Now it works. SUPER->polish() is better...
But what really worries me, is the fact, that it sometimes
worked
and sometimes crashed.
How can it be, that I start one programm, one time it
crashes, then it works 5 times, then it crashes again...
I thought computers are deterministic???
(I don't see a time dependence)
Michael

[germain garand]

Logged In: YES
user_id=145773

>Yes, that's it! Now it works. SUPER->polish() is better...
>But what really worries me, is the fact, that it sometimes
>worked
>and sometimes crashed.

Since then, have you tried to run your program e.g 30 times
to see if it really don't crashes at all ?

>How can it be, that I start one programm, one time it
>crashes, then it works 5 times, then it crashes again...
>I thought computers are deterministic???

Oh yes they are, but only when programs are totally bug
free... :-/
In powerful languages such as C/C++, you are given full
control on the machine, but you are also given the rope to
hang you.
For instance, if you operate with pointers, which are
variables pointing to direct memory addresses, and the
memory address stored in one pointer is wrong (the most
common case leading to the random behaviour you see is when
the pointer was not initialised and point to a random memory
address... that's a "wild pointer", something very
dangerous), sometimes you'll be "lucky" and the pointer will
still point to a valid memory range, other times the memory
address will be out of range and will trigger a SIGSEGV.
Here I really don't understand why this->SUPER:: could
generate such a pointer.
I'll need to run one of those database program through
valgrind to locate the invalid read/write.

[Michael Traxler]

Logged In: YES
user_id=623079

Hi Germain,

Yes, I tested it 50 times, no crash!
I'm used to buggy programs with dangling pointers (which I
write...), but the random behaviour I experienced so far were:
1) They are working as long as I don't change something
essential (power off)
2) Then they are not working at all, until the pointer in
the memory is set again by some other routine...
What's new for me (I normally program on custom built
hardware, DSPs), is the it works, next try not working, next
try working again. And the physical memory should normally
be the same, when no other users and daemons are working on
the system.
But I'm a c-programmer, not c++....
Michael

[germain garand]

Logged In: YES
user_id=145773

> I'm used to buggy programs with dangling pointers (which I
> write...),

Ooops... excuse me, I forgot you where also a C
programmer... I bet you know pointers better than me indeed,
as C++ don't use them often.

For the erratic behaviour, I think its related to a
corruption of the Perl stack when calling this->SUPER:: but
I can't investigate deeper for my debugging enabled Qt/Smoke
don't have the MySQL driver.
On my machine, this->SUPER::polish() consistently crashes
anyway =)