Cause
The script keeps more data in memory than TradingView allows. According to TradingView's documentation (error RE10139), the most common cause is a request.*() call that returns a collection or an object, such as an array: every bar of the chart then stores its own copy of what the request returned. When the collection grows bar after bar, the copies add up quickly, and on an intraday chart with a long history the script stops. Tables or drawings updated on every historical bar, very large max_bars_back values and thousands of strategy orders also use memory.
Broken code
This script compiles, but stops on the chart with the error above.
//@version=6
indicator("Average daily range")
// Builds a growing array of daily ranges inside the request
ranges() =>
var array<float> list = array.new<float>()
list.push(high - low)
list
// Returns the array on every bar: each chart bar keeps its own copy
array<float> daily = request.security(syminfo.tickerid, "D", ranges())
plot(na(daily) ? na : daily.avg())Fixed code
The same script, corrected for Pine Script v6. Paste it into the Pine Editor and save.
//@version=6
indicator("Average daily range")
// Keeps the array inside the request and returns only the result
avgRange() =>
var array<float> list = array.new<float>()
list.push(high - low)
list.avg()
float dailyAvg = request.security(syminfo.tickerid, "D", avgRange())
plot(dailyAvg)Why it works
The array now stays inside the requested function, on the daily timeframe, and the request returns one number per bar instead of a copy of the whole array. The result on the chart is the same average, without the memory that the copies used. When you do need the collection itself, return it only where you use it, for example barstate.islast ? list : na inside a tuple, so the other bars store na.
Other causes and fixes
- Tables. Create a table once with
varand fill its cells only on the last bar (if barstate.islast), instead of redrawing it on every historical bar. - Drawings. Update existing lines, labels and boxes with their setter functions rather than creating new ones on each bar.
- History buffers. Keep
max_bars_backas small as the script really needs; referencing values thousands of bars back makes the buffers large. - Lower-timeframe requests.
request.security_lower_tf()returns an array for every bar. Limit the number of chart bars it runs on withcalc_bars_count. - Strategies. Thousands of orders and trades take memory too: start the backtest from a recent date.
The other runtime limits, such as the number of requests per script, have their own pages in the Pine Script errors reference.
Questions
Why does Memory limits exceeded only happen on some charts?
Memory use grows with the number of bars the script runs on. The same script can work on a daily chart and stop on a 1-minute chart with a long history, because every bar stores its own copy of what the script keeps.
Can request.security() return an array in Pine Script v6?
Yes, it can return arrays, matrices, maps and objects. But each chart bar keeps a copy of the returned collection, so return a calculated value, or the collection only on the bars that need it.
The scripts on this page are minimal examples written to show the error and its fix, not trading systems. Trading involves substantial risk of loss and is not suitable for every investor. Edgoro is a software tool, not a broker or financial adviser: nothing it produces is investment advice, and past or backtested performance does not guarantee future results.