Issue Details (XML | Word | Printable)

Key: CORE-2829
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Adriano dos Santos Fernandes
Reporter: Adriano dos Santos Fernandes
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Some queries raises bugcheck 232 - EVL_expr: invalid operation

Created: 27/Jan/10 02:22 PM   Updated: 28/Feb/11 10:40 AM
Component/s: Engine
Affects Version/s: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.1.0, 2.0.4, 2.5 Alpha 1, 2.1.1, 2.0.5, 2.1.2, 2.5 Beta 1, 2.5 Beta 2, 2.1.3, 3.0 Initial, 2.5 RC1
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Duplicate
 

Planning Status: Unspecified


 Description  « Hide
If some aggregate expression of a lower context is inside some expressions like IN, ANY, ALL, it's generated invalid BLR. Example:

select id from account where id in (select count(id) from rdb$database);

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 27/Jan/10 05:12 PM
Could it be related to CORE-1605?

Adriano dos Santos Fernandes added a comment - 29/Jan/10 02:20 PM
They seems related (in the sense of wrong BLR instead of proper error, and the bugcheck message). The cause should also be related, that seems missing nodes not being visited, but different ones.

So if you like to mark that as duplication, feel free. I current have no solution and real knowledge of what exactly is wrong.

Adriano dos Santos Fernandes added a comment - 11/Feb/10 11:19 PM
Another type of query raising this error. When aggregate is used as the second argument of LIST:
    select list(1, count(*)) from t;

Adriano dos Santos Fernandes added a comment - 17/Feb/10 01:43 PM
Another problematic query (per CORE-2872):
select 1 from rdb$database where count(*) >= all (select count(*) from rdb$database);

Miroslav Djorov added a comment - 25/Feb/11 01:22 PM
Firebird version 2.1.3

I have two queries that use similar statements. In the first the statements are in SELECT section, in the second they are in the WHERE section:
SELECT
    NAST.ID,
    COALESCE(SUM(SMETKI_EL.SUMA *
        (
        SELECT FIRST 1
            KURS_HISTORY.KURS
        FROM
            KURS_HISTORY
        WHERE
            KURS_HISTORY.VAL_ID = SMETKI_EL.VAL_ID
            AND KURS_HISTORY.OPR_ID < SMETKI_EL.OPR_ID
        ORDER BY KURS_HISTORY.ID DESC
        )
    ),0.00) AS SUMA,
    SUM(COALESCE(
        (
        SELECT
            SUM(SMT_PAY_NODE.SUMA)
        FROM
            SMT_PAY_NODE
        WHERE
            SMT_PAY_NODE.SMETKA_EL_ID = SMETKI_EL.ID
        )
    ,0.00)) AS SUMA_PAY
FROM
    NAST LEFT JOIN SMETKI_EL ON SMETKI_EL.DEF_NAST_ID = NAST.ID
WHERE
    NAST.NAST_ID = :TIT_ID
    AND NAST.ROOM_ID = :ROOM_ID
GROUP BY 1

and

SELECT
    SMETKI_EL.ID
FROM
    SMETKI_EL
WHERE
    SMETKI_EL.DEF_NAST_ID = :OLD_TIT_ID
    AND (COALESCE(SMETKI_EL.SUMA *
        (
        SELECT FIRST 1
            KURS_HISTORY.KURS
        FROM
            KURS_HISTORY
        WHERE
            KURS_HISTORY.VAL_ID = SMETKI_EL.VAL_ID
            AND KURS_HISTORY.OPR_ID < SMETKI_EL.OPR_ID
        ORDER BY KURS_HISTORY.ID DESC
        )
    ,0.00) - SUM(COALESCE(
            (
            SELECT
                SUM(SMT_PAY_NODE.SUMA)
            FROM
                SMT_PAY_NODE
            WHERE
                SMT_PAY_NODE.SMETKA_EL_ID = SMETKI_EL.ID
            )
    ,0.00)) <> 0.00)
ORDER BY 1

After I've added the part with -SUM(...) in the second query the execution gives this error:
"Internal gds software consistency check (EVL_expr: invalid operation (232), file evl.cpp line: (1168)."
And after that the DB is corrupted.

Dmitry Yemanov added a comment - 25/Feb/11 03:25 PM
What exactly do you mean by "DB is corrupted"?

Miroslav Djorov added a comment - 28/Feb/11 08:00 AM
When I've wrote the last message, database validation showed errors in the database. But today I'm making more tests and I can't reproduce the corruption of the database.
On Friday consistency check (ca there were some test applications working with the database. All of them got "internal gds softwaren't continue after bugcheck)"
error when I executed the query above. And I had to kill all apps and I've restarted Firebird. Maybe the corruption of the database I saw, was a side effect of these actions.
I'm not sure. But today I can't reproduce the corruption of the database file. The only thing is that all connections to the database in the time when I execute
the query get "internal gds software consistency check (can't continue after bugcheck)"

Adriano dos Santos Fernandes added a comment - 28/Feb/11 10:40 AM
After a bugcheck, any command raises bugchecks until you close a database, to prevent more problems.

*This* bugcheck do not corrupt the databases.