Segfault/Stackoverflow when training a LSTM unit

[jonathanBieler]

I'm not sure if I did something wrong, but this crashes after a few iterations:

using Flux

m = LSTM(4, 1)

x = [zeros(4) for i=1:100]
y = zeros(100)
y[50:end] = 1

loss(x,y) =  Flux.mse(map(x->sum(m(x)),x), y)

L = loss(x,y)

Flux.back!(L)

data = [(x,y)]
opt = ADAM(Flux.params(m))
for i=1:10
    Flux.Optimise.train!(loss, data, opt)
end

Error is :

ERROR: StackOverflowError:
Stacktrace:
 [1] foreach(::Function, ::Tuple{TrackedArray{…,Array{Float64,1}}}, ::Tuple{Array{Float64,1}}, ::Vararg{Tuple{Array{Float64,1}},N} where N) at ./abstractarray.jl:1734
 [2] back_(::Flux.Tracker.Call{Flux.Tracker.Broadcasted{NNlib.#σ,Array{ForwardDiff.Dual{Void,Float64,1},1}},Tuple{TrackedArray{…,Array{Float64,1}}}}, ::Array{Float64,1}, ::Array{Float64,1}) at /Users/jbieler/.julia/v0.6/Flux/src/tracker/back.jl:25
 [3] back(::Flux.Tracker.Tracked{Array{Float64,1}}, ::Array{Float64,1}) at /Users/jbieler/.julia/v0.6/Flux/src/tracker/back.jl:38
 [4] macro expansion at /Users/jbieler/.julia/v0.6/Flux/src/tracker/back.jl:49 [inlined]
 [5] (::Flux.Tracker.##56#58)(::TrackedArray{…,Array{Float64,1}}, ::Array{Float64,1}) at /Users/jbieler/.julia/v0.6/Flux/src/tracker/array.jl:385
 [6] foreach(::Function, ::NTuple{4,TrackedArray{…,Array{Float64,1}}}, ::NTuple{4,Array{Float64,1}}, ::Vararg{NTuple{4,Array{Float64,1}},N} where N) at ./abstractarray.jl:1734
 [7] back_(::Flux.Tracker.Call{Flux.Tracker.Broadcasted{Flux.##113#116,Array{ForwardDiff.Dual{Void,Float64,4},1}},NTuple{4,TrackedArray{…,Array{Float64,1}}}}, ::Array{Float64,1}, ::Array{Float64,1}) at /Users/jbieler/.julia/v0.6/Flux/src/tracker/back.jl:25

I'm on Flux master, v0.6.2.

[MikeInnes]

You'll need to call trim! or reset! at some point, otherwise the LSTM builds up an arbitrarily long history that you have to backprop through.

[jonathanBieler]

My bad I missed that. That said if it could fail gracefully instead of killing Julia it would be nice, if that's possible.

[MikeInnes]

I agree, and I don't like that this is so easy to get wrong, but I'm not sure what we can do here. Something like #244 might help, but it might just be a case of waiting for #86.