Geek Answers Handbook

What causes "ArgumentError (dump format error)"?

During troubleshooting at Spree, where the product list was not paginated and only listed the first 10 products or so, I tried to reproduce the error in my local development environment and when I loaded the first page, I got the error:

ArgumentError (dump format error)

As always, first I tested my other brain. Top search result: https://github.com/rails/rails/issues/2509

Although the user who started this thread and several other posters tried to upgrade from Rails 3.0.9 to Rails 3.1, I did not think that this applied to my case. The Spree 0.60.2 application that I run is in Rails 3.0.9.

However, as it turned out, just clearing my localhost cookies solved the problem. Why?

+7
source share
5 answers

I am going to assume that since I run several applications in my development environment, including the Rails 3.1 / Spree 0.70 version of the same application, and I visit them through localhost that there is a conflict something like cookies, where version 3.1 set some files cookies that version 3.0.9 could not eat. This is probably due to what @Fjan mentioned in his post here ( https://github.com/rails/rails/issues/2509 ):

I traced this error, and this is because the FlashHash class in the session has been changed so that it no longer inherits from the Hash class in rails 3.1.

I did an experiment. If I did not enter one of the versions of the application, I could start it and close it, and start another and not run into this problem. However, when I entered version 3.0.9 and then turned off this server and started version 3.1, I got the same error again. Here is a partial trace:

activesupport (3.1.1) lib / active_support / message_verifier.rb: 34: in load' activesupport (3.1.1) lib/active_support/message_verifier.rb:34:in check' actionpack (3.1.1) lib / action_dispatch / middleware / cookies.rb: 280: in []' actionpack (3.1.1) lib/action_dispatch/middleware/session/cookie_store.rb:53:in block in unpacked_cookie_data' actionpack (3.1.1) Library / action_dispatch / intermediate / session / abstract_store .rb: 55: at stale_session_check!' actionpack (3.1.1) lib/action_dispatch/middleware/session/cookie_store.rb:51:in stale_session_check!' actionpack (3.1.1) lib/action_dispatch/middleware/session/cookie_store.rb:51:in unpacked_cookie_data 'rack (1.3.6) lib / rack / session / cookie.rb: 96: in extract_session_id' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:51:in block in extract_session_id 'actionpack (3.1.1) library / action_dispatch / intermediate / session / abstract_store.rb: 55: in stale_session_check!' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:51:in stale_session_check!' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:51:in extract_session_id 'rack (1.3.6) lib / rack / session / abstract / id.rb: 43: in load_session_id!' rack (1.3.6) lib/rack/session/abstract/id.rb:32:in load_session_id!' rack (1.3.6) lib/rack/session/abstract/id.rb:32:in : in current_session_id' rack (1.3.6) lib/rack/session/abstract/id.rb:258:in session_exists? 'rack (1.3.6) lib / rack / session / abstract / id.rb: 104: in exists?' rack (1.3.6) lib/rack/session/abstract/id.rb:114:in exists?' rack (1.3.6) lib/rack/session/abstract/id.rb:114:in load_for_read! 'rack (1.3.6) lib / rack / session / abstract / id.rb: 64: in has_key?' actionpack (3.1.1) lib/action_dispatch/middleware/flash.rb:260:in has_key?' actionpack (3.1.1) lib/action_dispatch/middleware/flash.rb:260:in provide when calling 'actionpack (3.1.1) lib / action_dispatch / middleware / flash.rb: 261: in call' rack (1.3.6) lib/rack/session/abstract/id.rb:195:in context "rack (1.3.6) lib / rack / session / abstract / id.rb: 190: in` call '

The converse is also true. When I entered version 3.1, and then turned off this server and started version 3.0.9, I got the same error. Here is a partial trace:

activesupport (3.0.9) lib / active_support / message_verifier.rb: 34: in load' activesupport (3.0.9) lib/active_support/message_verifier.rb:34:in check' actionpack (3.0.9) lib / action_dispatch / middleware / cookies.rb: 253: in []' actionpack (3.0.9) lib/action_dispatch/middleware/session/cookie_store.rb:68:in block unpacked_cookie_data' actionpack (3.0.9) library / action_dispatch / middleware / session / abstract_store.rb: 223: at stale_session_check!' actionpack (3.0.9) lib/action_dispatch/middleware/session/cookie_store.rb:66:in stale_session_check!' actionpack (3.0.9) lib/action_dispatch/middleware/session/cookie_store.rb:66:in unpacked_cookie_data 'actionpack (3.0.9) library / action_dispatch / middleware / session / cookie_store.rb: 57: in extract_session_id' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:39:in load_session_id! actionpack (3.0.9) lib / action_dispatch / middleware / session / abstract_store.rb: 27: in []' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:210:in current_session_id' actionpack (3.0 .9) Library / action_dispatch / middleware / session / abstract_store.rb: 239: in exists?' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:96:in exists?' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:96:in exists? actionpack (3.0.9) Library / action_dispatch / intermediate / session / abstract_store.rb: 113: in load_for_read!' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:53:in load_for_read!' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:53:in [] actionpack (3.0.9) lib / action_dispatch / middleware / flash.rb: 178: in call' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:149:in Call '

What is noteworthy for me is that you do not need to be literally updated. To reproduce this problem, you only need to run two applications covering these two versions of Rails that set cookies with the same name ... presumably either sequentially (as in my experiment), or simultaneously (which I have not tried yet).

Hopefully someone else will provide a more informed answer than this, in order to add the details that are missing in this free explanation. In the meantime, if you encounter this problem during the development process and you don’t need internal actions, just clear the cookies (as suggested by @tscolari in the stream above: https://github.com/rails/rails/issues/2509 ) and move forward. Greetings.

+10
source

I ran into the same problem. Clearing the cookie browser solved the problem. development mode.

+3
source

Clearing cookies will solve this problem, try opening the application using another browser or incognito on chrome, this will work fine.

+2
source

If you work and you cannot ask your users to clear cookies :) - the only way is to change the session_store key in config / initializers / session_store.rb

The solution is not very pleasant, the user will have to re-enter the system.

+2
source

I encountered the same problem in production right after the transition to rails 3.2.

The change to the session_store key suggested by @povkys would be too redundant in my case, since only some users (less than 1%) encountered problems in their sessions.

I ended up working with a script to parse all the sessions in the database and delete those that are invalid. Here is the code if it helps someone:

 current_id = 0 failed_count = 0 while (sessions = ActiveRecord::Base.connection.select_all("Select id, data from sessions where id > #{current_id} limit 1000")).count > 0 do failed_ids = [] sessions.each do |s| begin ActiveRecord::SessionStore::Session.unmarshal(s['data']) rescue failed_count += 1 failed_ids.push s['id'] end end ActiveRecord::Base.connection.execute("DELETE FROM sessions WHERE id in (#{failed_ids.join ','})") unless failed_ids.empty? current_id = sessions.last['id'] end failed_count
0
source

More articles:


All Articles