Subject | Re: [firebird-support] firebird crash confirmation |
---|---|
Author | Helen Borrie |
Post date | 2004-10-27T23:17:11Z |
Mihai,
At 08:41 PM 27/10/2004 +0000, you wrote:
tracker. See my comments at the bottom, though.
Post the bug report ASAP, so it can be added to the current round of QA
testing for the 1.5.2 release.
CODE:335544652, "multiple rows in singleton select", which I think helps to
pinpoint where the AV is occurring.
./heLen
At 08:41 PM 27/10/2004 +0000, you wrote:
>Hi all,Confirmed. It's a good bug report - go ahead and put it in the
>
>I want to get a confirmation, before posting this on firebird bug
>tracker, for a bug that makes the firebird server crash.
>I discovered this bug while working on an ERP sotftware by running a
>select query. The server crashes every time I run the query. I've
>manage to simplify the query and to produce a simple script that kills
>the server when executed.
tracker. See my comments at the bottom, though.
Post the bug report ASAP, so it can be added to the current round of QA
testing for the 1.5.2 release.
>Tested on:The server doesn't crash...but these two queries fail with ISC ERROR
>OS: Windows 2000 Profesional SP4
>DB: Firebird-1.5.1.4481-Win32.exe (with default configuration)
>CPU: AMD Athlon XP 2200+
>RAM: 512MB
>
>and
>
>OS: Windows 2000 Profesional SP4
>DB: Firebird-1.5.0 (with default configuration)
>CPU: AMD Athlon XP 2200+
>RAM: 512MB
>
>and
>
>OS: Windows 2000 Profesional SP4
>DB: Firebird-1.5.1.4481-Win32.exe (with default configuration)
>CPU: Intel Celeron 2GHz
>RAM: 256MB
>
>The message from system log:
>Application popup: 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
>
>-------------
>
>This is the script:
>/* Table: TB1 */
>CREATE TABLE TB1 (
> TB1_ID INTEGER NOT NULL,
> CREATE_DATE TIMESTAMP NOT NULL);
>
>commit;
>
>/* Table: TB2 */
>CREATE TABLE TB2 (
> TB2_ID INTEGER NOT NULL,
> QUANTITY NUMERIC (18, 3) NOT NULL,
> TB1_ID INTEGER);
>
>commit;
>
>/* TB1 data */
>INSERT INTO TB1 VALUES (1, '10/26/2004');
>INSERT INTO TB1 VALUES (2, '10/27/2004');
>
>/* TB2 data */
>INSERT INTO TB2 VALUES (1, 3, 1);
>INSERT INTO TB2 VALUES (2, 5, 1);
>INSERT INTO TB2 VALUES (3, 1, 2);
>INSERT INTO TB2 VALUES (4, 7, 2);
>
>commit;
>
>/* this is the select query that kills the server */
>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
>
>---------------
>Runing the select kills the server, but if 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
>
>or
>
>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
>
>everything it's ok (the server doesn't crash).
CODE:335544652, "multiple rows in singleton select", which I think helps to
pinpoint where the AV is occurring.
./heLen