Compile-time hashes causing crash with syntax error

Misstake · 2019-09-12T19:19:24.645Z

When a comma is forgotten in an array declaration when using compile-time hashing instead of giving a syntax error the whole client simply crashes.

I’ll attach the log and dump just in case but looks like an easy to reproduce issue.

The code which caused the crash is listed below, it crashes when loading the plugin with the comma forgotten, seems like a minor issue, but a simple try catch would propbably suffice to fix something like this.

local trackedEntities = {
    `prop_roadcone02a`,
    `prop_barrier_work05`,
    `p_ld_stinger_s`,
    `prop_boxpile_07d`,
    `hei_prop_cash_crate_half_full`
    'prop_mp_arrow_barrier_01`,
    'prop_mp_barrier_01`
}

d64fbf1c-59cf-48e2-b5ab-e7552285c56d.dmp (9.0 MB)
CitizenFX.log.1 (410.8 KB)

fluorine · 2019-09-13T17:39:45.265Z

This doesn’t seem to repro here - placing this in an empty resource client script still works fine. Do you have a more complete repro?

glitchdetector · 2019-09-13T18:43:06.952Z

Misstake:

`prop_boxpile_07d`, 
`hei_prop_cash_crate_half_full` 
'prop_mp_arrow_barrier_01`,

Well, there’s a missing comma at the end of the hei_prop_cash_crate_half_full line
The last two entries start with a single quote instead of a backtick

A syntax error indeed, not sure about the crash though

Misstake · 2019-09-14T02:57:39.980Z

Seems like the crash doesn’t work when ther’s another syntax error. I already got rid of the compile-time hashing, since the crashing risk. But the working repro is:

local trackedEntities = {
    `prop_roadcone02a`,
    `prop_barrier_work05`,
    `p_ld_stinger_s`,
    `prop_boxpile_07d`,
    `hei_prop_cash_crate_half_full`
    `prop_mp_arrow_barrier_01`,
    `prop_mp_barrier_01`
}

With this as __resource.lua:

resource_manifest_version '44febabe-d386-4d18-afbe-5e627f4af937'

client_scripts {
    'client.lua'
}

That worked for me. So a simple array definition with compile-time hashing (backticks) and only 1 comma missing.

thulium · 2019-09-14T04:32:21.190Z

Right. This seems to be a case of missing token handling in llex.c (txtToken), where TK_HASH (nor the former TK_PATH or whatever it was) is not part of the logic to handle syntax errors, leading to a weirdly invalid pointer being referenced.

Fixed as of

github.com/citizenfx/fivem

vendor/lua: fix lexer error reporting for hash tokens

committed 04:34AM - 14 Sep 19 UTC

+2 -2