【问题标题】:What causes the "ArgumentError (dump format error)"?是什么导致“ArgumentError(转储格式错误)”?
【发布时间】:2012-02-02 21:47:35
【问题描述】:

在解决 Spree 中产品列表未分页且仅列出前 10 个左右产品的不当行为时,我尝试在本地开发环境中重现该错误,并在第一个页面加载时收到错误:

ArgumentError (dump format error)

和往常一样,我首先检查了我的另一个大脑。最高搜索结果是:https://github.com/rails/rails/issues/2509

虽然发起该主题的用户和其他几位发帖人都在尝试从 Rails 3.0.9 升级到 Rails 3.1,但我认为这不适用于我的案例。我正在运行的 Spree 0.60.2 应用程序是 Rails 3.0.9。

然而,事实证明,只需清除我的本地主机 cookie 即可解决问题。为什么?

【问题讨论】:

    标签: ruby-on-rails-3 spree rails-3-upgrade


    【解决方案1】:

    我将推测,因为我在我的开发环境中运行多个应用程序,包括同一应用程序的 Rails 3.1/Spree 0.70 版本,并且我通过 localhost 访问所有这些应用程序,所以存在冲突cookie 中的某种类型,其中 3.1 版本设置了一些 3.0.9 版本不能吃的 cookie。这可能与@Fjan 在他的帖子 (https://github.com/rails/rails/issues/2509) 中提到的有关:

    我跟踪了这​​个错误,它发生是因为 FlashHash 类在 session 已更改为不再从 Hash 类中继承 轨道 3.1。

    我做了一个实验。如果我没有在任一版本的应用程序上登录,我可以启动一个并关闭它并启动另一个,并且不会在任何一个版本上遇到这个问题。但是,当我登录 3.0.9 版本然后关闭该服务器并启动 3.1 版本时,我再次收到相同的错误。这是部分跟踪:

    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' 动作包 (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' 动作包 (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' 机架 (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 在 extract_session_id' 动作包 (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' 机架 (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[]' 机架 (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?架子 (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!'机架 (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'

    反过来也是如此。 当我登录 3.1 版本然后关闭该服务器并启动 3.0.9 版本时,我收到了同样的错误。这是部分跟踪:

    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' 动作包 (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' 动作包 (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' 动作包 (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!动作包 (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 存在吗?动作包 (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'

    对我来说值得注意的是,您不必真正处于升级过程中。要重现此问题,您只需要运行两个跨过这两个版本的 Rails 的应用程序,它们正在设置具有相同名称的 cookie……可能是按顺序(如在我的实验中)或同时(我还没有尝试过)。

    希望这里的其他人会提供比这更明智的答案,以添加这种松散解释所缺乏的细节。同时,如果您在开发过程中遇到此问题并且您不关心内部工作,只需清除您的 cookie(如 @tscolari 在上面引用的线程中所建议:https://github.com/rails/rails/issues/2509)并继续前进。干杯。

    【讨论】:

    • 所以基本上这只发生在开发中?我不认为是这样。我没有同时运行两个应用程序。
    • 这个问题并不是开发环境所独有的,只是在那里遇到的可能性更大。如果您在升级过程中,您很可能会在生产环境中遇到此问题。你的背景是什么。
    • 我们构建了一个 gem 来简化不同 rails 版本之间的 flash 迁移:github.com/envato/rails_4_session_flash_backport
    【解决方案2】:

    如果您在生产中并且您不能要求您的用户清除 cookie :) - 唯一的方法是更改​​ config/initializers/session_store.rb 中的 session_store 键

    解决方案不好,用户必须重新登录。

    【讨论】:

      【解决方案3】:

      我遇到了同样的问题。清除浏览器 cookie 解决了这个问题。开发模式。

      【讨论】:

        【解决方案4】:

        清除您的 cookie 将解决此问题,尝试使用其他浏览器或在 Chrome 上隐身打开您的应用,它会正常工作。

        【讨论】:

          【解决方案5】:

          在迁移到 Rails 3.2 后,我在生产中遇到了同样的问题。

          在我的情况下,按照@povkys 的建议更改 session_store 密钥有点矫枉过正,因为只有一些用户(不到 1%)的会话出现问题。

          我最终运行了一个脚本来解析数据库中的所有会话并删除那些无效的会话。这是代码,以防它帮助某人:

          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
          

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2011-01-07
            • 2019-08-31
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多