SystemStackError (stack level too deep) in Hyrax::FileSetsController#destroy #4581
Comments
|
@conorom I dealt with something similar in avalon hitting stack level too deep when it hadn't been a problem before. I ended up creating a monkey patch: https://github.com/avalonmediasystem/avalon/blob/master/config/initializers/active_fedora_general.rb#L11-L19 |
|
Is it safe to say that all versions in-between 2.8.0 and 3.0.0.pre.rc2 are affected in the same way? |
|
@bwatson78 That's a good question. I'm not sure what version of Hyrax, ActiveFedora, or other dependency like ActiveTriples or Rails this problem was introduced with and which it still affects. |
|
@cjcolvar Thanks v much for sharing the monkey patch. I tested it in Fulcrum/heliotrope a few times and it seems to resolve the problem. @bwatson78 I would be very surprised if the issue didn't affect all versions between the two I have tested, and probably more besides. |
|
@cjcolvar i'm wondering if you have any breadcrumbs i could follow to lead me to the same conclusions as your AF monkey patch? my initial reaction was that this likely originates as an issue with the result of the ingest, rather than the w = FactoryBot.create(:work_with_files)
250.times do
f = FactoryBot.create(:file_set, :image)
w.members << f
end
w.save
w.reload
w.members.to_a.count # => 252
w.members.each(&:destroy)i was hoping that this would raise the issue, but no luck. i might try again in the morning with threads---i half suspect a race condition. it could also just be a bug in |
|
i created 300 i guess the next step is to try to do the creation through the controller. if anyone has any insight about working up a reproducible example, it would be a huge help; else, i'll keep chugging along. w = FactoryBot.create(:work_with_files)
threads = []
3.times do
threads << Thread.new do
100.times do
w.ordered_members << FactoryBot.create(:file_set, :image)
w.save
end
end
end
threads.each(&:join)
w.ordered_members.to_a.each(&:destroy) |
|
@no-reply In case it's helpful I just poked around in Slack where the content editor first reported this. I can see in the Rails console that the two Works in question were created using our CSV importer (which uses the actor stack) and not the UI/controller. In my tests I uploaded the files through the UI each time. Seems like how the FileSets were added to the Work isn't relevant. Maybe. I can also conform that the editor ended up deleting the offending FileSets successfully in the Rails console after several UI attempts had failed. This is why I emphasized the UI in the description. UI deletion is the problem, I think. |
oh, this does help! it sounds like i should start at the actor stack, both on the create and delete sides. thanks for the info! |
|
I believe we've hit a similar error to this in our somewhat-modified Hyrax application (currently running on 2.9.0) using many different work types with many different parent-child relationships between works. Namely, if we have a work with over 120 or so child works, and we try to create a new child work nested inside the parent work (using the AddToWorkActor to accomplish the nesting), we hit a stack level too deep error on saving the parent work. @cjcolvar 's monkey-patch seems to have fixed this error for us (thanks!), but I'm not yet finished testing things after adding it. |
…ered list when calling nodes_will_change! which leads to a stack level too deep exception in some cases See samvera/hyrax#4581 This approach was also taken in ActiveFedora::File: See 7c8bbbe#diff-28356c4daa0d55cbaf97e4269869f510R100-R103
…ered list when calling nodes_will_change! which leads to a stack level too deep exception in some cases See samvera/hyrax#4581 This approach was also taken in ActiveFedora::File: See 7c8bbbe#diff-28356c4daa0d55cbaf97e4269869f510R100-R103
…ered list when calling nodes_will_change! (#1442) which leads to a stack level too deep exception in some cases See samvera/hyrax#4581 This approach was also taken in ActiveFedora::File: See 7c8bbbe#diff-28356c4daa0d55cbaf97e4269869f510R100-R103
|
can anyone confirm that this issue still exists in 3.0.0.pre.rc2? according to samvera/active_fedora@2b49516, this is already fixed in most recent ActiveFedora, but the original ticket claims it's an issue in Hyrax 3.0.0-rc2 |
|
@no-reply well I popped onto Nurax, now on Full disclosure, I dunno what any of this does or why the monkey patch works, but I think I see your confusion. Maybe. Looks like the commit you reference was only merged yesterday, though the comment states the workaround is based on one added here. It doesn't help that that line range link doesn't work (i.e. jump and highlight lines 100-103 of |
that's right on the other hand, it's also using Rails 5.1 (but ActiveModel 5.2), so maybe that's implicated? |
|
Can this be closed with the release of ActiveFedora 12.2.3? Or is investigation still needed to determine if it is still present in ActiveFedora 13+? |
|
Nurax is definitely running AF 13.x, so I think this is still an issue
…On Thu, Mar 25, 2021, 3:10 PM Chris Colvard ***@***.***> wrote:
Can this be closed with the release of ActiveFedora 12.2.3? Or is
investigation still needed to determine if it is still present in
ActiveFedora 13+?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4581 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKMO4DKJIJ25EKR3PRLXQTTFOYDVANCNFSM4TVAKMIQ>
.
|
|
I am seeing a very similar looking error when running large imports. The background is that I had some github/dependabot alerts relating to actionpack, actionview and activesupport. I moved rails from 5.1.6.2 to 5.2.6 to pick up the equivalent verions of actionpack, actionview and activesupport, and to test I submitted several imports (via a custom version of bulkrax) where works getting > 50 images attached. AttachFilesToWorkJob fails in Sidekiq with 'SystemStackError: stack level too deep', log file attached. My log looks pretty similar to the description in issue 4581, although mine is not a delete of images. We are using Hyrax 2.9.5, and active-fedora is at 12.1.1 in gemfile.lock. Apologies if this is unrelated to this issue, but posting here in case bumping to 5.2.* is somehow involved |
|
I am able to reproduce this in dassie by creating a large work via the UI as described, no deletion step required. This is while using active fedora 13 and the suggested I'll note that the number of files that can be attached by upload is limited (to 100?), so the error is not seen at initial creation, but later when adding an additional set of 100 files. It seems possible to me this is not a case of circular method calls, but recursive calls for each FileSet. |
|
I dug into the debugger looking at what My suggestion, and what worked for my application, is to simply raise the limit. This would need to be added to deployment and/or troubleshooting documentation. See IU-Libraries-Joint-Development/essi#355 where I added |
|
@jlhardes Adding a section to https://github.com/samvera/hyrax/wiki/Hyrax-Management-Guide#production-concerns seems like a good place to document this. edit: Done. https://github.com/samvera/hyrax/wiki/Hyrax-Management-Guide#stack-size |
|
I was able to get further before a stack overflow error with the following two changes that shift resource use from the stack to the heap: def save_contained_resources
# Split into two steps due to stack overflow issue while saving works with large numbers of ordered members
changed = contained_resources.changed
keys = []
keys = changed.keys if changed.size > 0
i = 0
n = keys.size
while i < n do
resource = changed[keys[i]]
resource.save
i += 1
end
end
The second change, which I am less sure about being correct, is in: def each_statement
ancestors = @ancestors.dup
if block_given?
statements = source_graph.query(subject: starting_node).each
statements.each_statement { |st| yield st }
ancestors << starting_node
ebd_to_process = []
statements.each_object do |object|
next if object.literal? || ancestors.include?(object)
ebd_to_process << ExtendedBoundedDescription.new(source_graph, object, ancestors)
end
statements = []
ebd_to_process.each do |ebd|
ebd.each { |statement| statements << statement }
end
statements.each { |statement| yield statement }
end
enum_statement
end
|
|
Closing since the solution to raise the memory limit has been documented. see: #4581 (comment) |
Based on recommendation for resolving "Stack level too deep" errors, found here: samvera/hyrax#4581 (comment)
Using the UI to delete a FileSet from a Work fails when the Work has "many" FileSets
2.8.0, 3.0.0.pre.rc2
Rationale
This seems to be a new issue or regression. Possibly in underlying gems. Apologies but I don't know enough about ActiveFedora/RDF to assign the issue to another gem.
Expected behavior
FileSet should be deleted as expected. I guess something is going wrong with rebuilding the ListSource (total guess). Something recursion-related, perhaps?
Actual behavior
Page spins for a while and then fails with
SystemStackError (stack level too deep)Steps to reproduce the behavior
aside: This is an easy way to make a bunch of small < 10KB files to use (causing minimal ingest overhead)
Stack trace from Nurax:
The text was updated successfully, but these errors were encountered: