CompilerException java.lang.RuntimeException: Method code too large! when debugging

[fgiasson]

Since version 0.11.0 and still with 0.12.0 I am often getting this error message when debugging:

CompilerException java.lang.RuntimeException: Method code too large!

Well, the error message is obvious, but I am wondering why it started to happen (never encountered it with version 0.10.0).

I am wondering if this is something new, and what is a function that is too large (how is this defined?).

Also, it will be returned whatever I use #dbg, #break or that instrumentalize the whole function.

Any ideas how I could increase the size supported (if possible), or..?

[Malabarba]

Is this happening consistently? What are the functions like?
I've run into this problem once or twice, but usually on very large functions.

[fgiasson]

@Malabarba yes, consistently with specific (longer) functions. However I am really wondering how is "a long function" defined :)

My functions doesn't appears to be particularly large, except if it includes other things that I am not aware in the calculation of the size.

Also, do you know if this is something that has to do with the latest version or is this something I didn't encounter before?

[Malabarba]

@Malabarba yes, consistently with specific (longer) functions. However I am really wondering how is "a long function" defined :)

I think only The Source could tell us that. :-)

My functions doesn't appears to be particularly large, except if it includes other things that I am not aware in the calculation of the size.

Macros could make functions much larger than they appear. But it's also unclear to me exactly when that happens.

Also, do you know if this is something that has to do with the latest version or is this something I didn't encounter before?

No, it's always been around. But it's possible that the current version has made the problem worse.

[fgiasson]

@Malabarba ok good to know.

Do you know what what returns this exception?

[fgiasson]

@Malabarba tell me if I am wrong, but probably that the debugger is getting the function's code, and then maybe add stuff to it and then compile it for debugging purposes (this is probably the instrumentalization process).

I can buy that this may happen when instrumentalizing relatively large functions. However, I am wondering why this would happen when using a #break or a #dbg in a small portion of the code. Probably because it has to add all the stuff to that function and to compile it the same way anyway?

Just a few thoughts, but I didn't look at the Cider code yet.

[Malabarba]

Yeah, it's really strange that it happens with #break. Break only adds a single macro to the function.
However, the instrumentation process also adds a ton of metadata to everything, so maybe that's the cause.

Perhaps we can solve this by clearing some of the metadata before evaluation.

[fgiasson]

@Malabarba Yeah this is what I thought about #break but obviously there seems to be an issue with it. If we can get this to work with #break and maybe with #dbg for small subsets, then I don't think this issue would be a real one. But not having any of these options comes an issue in my view.

Perhaps we can solve this by clearing some of the metadata before evaluation.

You mean, when doing the instrumentation? I don't think it would even be necessary if we can get #break to work (or maybe it is how to fix it :) )

[Malabarba]

Yes, that's what I meant. Clearing the metadata might be a way to fix #break. I'll cook up a snippet and ask you to run it, is that ok?

[fgiasson]

@Malabarba sure any time! Thanks.

[fgiasson]

@Malabarba any news on this?

[Malabarba]

Right, sorry.
Try evaluating this on a repl:

(in-ns cider.nrepl.middleware.debug)
(defmacro breakpoint-implementation [form {:keys [coor]} original-form]
  (let [val-form (cider.nrepl.middleware.util.meta/strip-meta
                  (if (looks-step-innable? form)
                    (let [[fn-sym & args] form]
                      ;; Evaluate args first, delaying the decision of whether or
                      ;; not to step in until the last possible moment.
                      `(let [args# [~@args]
                             step-in?# (step-in? (var ~fn-sym) ~coor)]
                         (apply (if step-in?#
                                  (::instrumented (meta (var ~fn-sym)))
                                  ~fn-sym)
                                args#)))
                    form))]
    `(let [val# ~val-form]
       (cond
         (skip-breaks? ~coor) val#
         ;; The length of `coor` is a good indicator of current code
         ;; depth.
         (= (:mode @*skip-breaks*) :trace)
         (do (print-step-indented ~(count coor) '~(cider.nrepl.middleware.util.meta/strip-meta original-form) val#)
             val#)
         ;; Nothing special. Here's the actual breakpoint logic.
         :else                (->> (pr-short val#)
                                   (assoc *extras* :debug-value)
                                   (read-debug-command val#))))))

See if it solves the issue.

[expez]

Method code too large...

[fgiasson]

@Malabarba it seems that it helped fixing the issue for one of my function, but I can still experience it in others when using #break

[expez]

I experience this problem on functions containing resource definitions for use with liberator. They are way too long in several places, but no one has had the time to break them up yet.