What causes the “ArgumentError (dump format error)”?

Question

While troubleshooting a misbehavior in Spree where the product list was not paginating and was only listing the first 10 products or so, I attempted to reproduce the error in my local development environment and on the first page load I received the error:

ArgumentError (dump format error)

As always, I checked my other brain first. The top search result was: https://github.com/rails/rails/issues/2509

Although the the user who started that thread and several of the other posters were attempting an upgrade from Rails 3.0.9 to Rails 3.1, I didn't think it would apply to my case. The Spree 0.60.2 app I'm running is at Rails 3.0.9.

However, as it turns out, simply clearing my localhost cookies solved the problem. Why?

Answer 1

I'm going to speculate that because I'm running multiple applications in my development environment, including a Rails 3.1/Spree 0.70 version of the same app, and I visit all of them via localhost, that there was a conflict of some sort in the cookies, where the 3.1 version set some cookie that the 3.0.9 version couldn't eat. It probably has to do with what @Fjan mentioned in his post here (https://github.com/rails/rails/issues/2509):

I traced this error and it happens because the FlashHash class in the session has been changed to no longer inherit from the Hash class in rails 3.1.

I ran an experiment. Provided I did not login on either version of the app, I could start one up and shut it down and start the other and not run into this problem on either. However, when I logged into the 3.0.9 version and then shut down that server and launched the 3.1 version, I received the same error once 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:inverify' 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:inblock in unpacked_cookie_data' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:55: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:inblock in extract_session_id' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:55: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[]' rack (1.3.6) lib/rack/session/abstract/id.rb:252:in current_session_id' rack (1.3.6) lib/rack/session/abstract/id.rb:258:insession_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:inload_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:inensure in call' actionpack (3.1.1) lib/action_dispatch/middleware/flash.rb:261:in call' rack (1.3.6) lib/rack/session/abstract/id.rb:195:incontext' rack (1.3.6) lib/rack/session/abstract/id.rb:190:in `call'

The reverse was also true. When I logged into the 3.1 version and then shut down that server and launched the 3.0.9 version, I received 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:inverify' 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:inblock in unpacked_cookie_data' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:223: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) lib/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) lib/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:113: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:incall'

What's notable to me is that you needn't literally be in the process of upgrading. To reproduce this issue, you need only be running two apps spanning these two versions of Rails that are setting cookies with the same names...presumably either in sequence (as in my experiment) or concurrently (which I haven't tried).

Hopefully, someone else here will provide a better-informed answer than this to add the details this loose explanation lacks. In the meantime, if you're running into this issue in development and you don't care about the inner workings, just clear your cookies (as suggested by @tscolari in the thread referenced above: https://github.com/rails/rails/issues/2509) and move along. Cheers.

Answer 2

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

The solution is not nice, user will have to re-login.

Answer 3

I faced the same issue. Clearing browser cookies solved the problem. development mode.

Answer 4

Clearing your cookies would solve this issue, try to open your app with a different browser or incognito on chrome it will work fine.

Answer 5

I ran into the same problem on production just after moving to rails 3.2.

Changing the session_store key as suggested by @povkys would have been a bit overkill in my case since only some users (less than 1%) got problems with their sessions.

I ended up running a script to parse through all the sessions in database and delete those that are invalid. Here is the code, in case 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