Subject Re: firebird crash confirmation
Author Mihai Chezan
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:
> Mihai,
>
> At 08:41 PM 27/10/2004 +0000, you wrote:
>
> The server doesn't crash...but these two queries fail with ISC ERROR
> CODE:335544652, "multiple rows in singleton select", which I think
helps to
> pinpoint where the AV is occurring.
>
> ./heLen

Hi Helen,

Could you tell me on what version of firebird did you run the script?
I ask you this because I use the 1.5.1 and I don't get the results you
say. And the fbserver does crash when executing the first select:
SELECT
TB1.CREATE_DATE,
'xxx' xxx,
SUM(TB2.QUANTITY)
FROM
TB1
INNER JOIN TB2
ON TB2.TB1_ID = TB1.TB1_ID
group by
1,
2

I get an error window:
---------------------------
fbserver.exe - Application Error
---------------------------
The instruction at "0x0048ae4e" referenced memory at "0x00000001". The
memory could not be "read".


Click on OK to terminate the program
Click on CANCEL to debug the program
---------------------------
OK Cancel
---------------------------

and after I click OK I get in isql (the script is executed in isql):
CREATE_DATE XXX SUM
========================= ====== =====================

1858-11-17 00:00:00.0000 0.000
Statement failed, SQLCODE = -901

connection lost to database

and the firebird.log:
xxx (Client) Wed Oct 27 15:36:31 2004
INET/inet_error: connect errno = 10061

If instead of the first select query I run:
SELECT
TB1.CREATE_DATE,
'xxx' xxx,
SUM(TB2.TB2_ID)
FROM
TB1
INNER JOIN TB2
ON TB2.TB1_ID = TB1.TB1_ID
group by
1,
2

I get (in isql):
CREATE_DATE XXX SUM
========================= ====== =====================

2004-10-26 00:00:00.0000 xxx 3
2004-10-27 00:00:00.0000 xxx 7

which is the correct result and if I run:
SELECT
TB1.CREATE_DATE,
CAST('xxx' AS CHAR(3)) xxx,
SUM(TB2.QUANTITY)
FROM
TB1
INNER JOIN TB2
ON TB2.TB1_ID = TB1.TB1_ID
group by
1,
2

I get:

CREATE_DATE XXX SUM
========================= ====== =====================

2004-10-26 00:00:00.0000 xxx 8.000
2004-10-27 00:00:00.0000 xxx 8.000

which is the correct result too.

I included these last two selects to show that the same select query
that crashes the server with little modification (the sum made on an
integer field instead on an numeric one, or a cast to char(3) over
'xxx') works.