Debugging a "binding stack not balanced" bug?

Question

I'm trying to figure out how to approach a bug I've run into. I assume it's actually a bug in Emacs, but I don't know the right way to make headway with it. In short, I'm getting the message "binding stack not balanced (serious byte compiler bug)" when I try to send an HTTP message. I don't know how to tell if this is caused by something I've done, if it's a bug in Emacs, a bug in some other code, or what, so any help pointing me in the right direction would be great.

Here's some more context. I'm sending an HTTP message from Emacs to a Python web service. The payload/content-type is JSON. Emacs starts and manages the Python server, and certain configuration options determine whether that server is running under Python 2 or Python 3. This would normally not be relevant for Emacs, but strangely this defect only manifests itself when the server is running with Python 3. With Python 2 everything works perfectly.

I don't know if the Python2/3 difference is a complete red herring or not. It could be that some difference in the details of the network traffic between Python 2 and 3 is causing this defect. Or it could be that the values of the elisp variables which control the Python version are to blame. Of those options the first seems more plausible, but both seem pretty far-fetched. In other words, I'm stumped.

If it will help, I can post the stacktrace showing where the error is generated.

ED: The stacktrace can be seen here.

Answer 1

Here is how I would debug this:

First, find the failing bytecode. This ought to be the function on the stack just before the call to error. In this case it seems to be open-network-stream.

Disassemble this method using disassemble. In order to understand this you may need to read through bytecode.c a bit, or maybe the bytecode compiler, depending on whether you like to read hairy C or hairy Lisp.

You should be able to find the unbalanced bindings by inspection -- by tracing through the code by hand.

After this you have to start debugging the bytecode compiler to find out where it has gone wrong. One approach might be to try to correlate the bad bytecode to forms in the failing function, and then try to reduce this to a more tractable test case (open-network-stream seems large-ish). This would make it simpler to track through the compiler.

If you just want to work around the bug, remove the .elc in question and reload it. Or, if it is dumped, just re-evaluate the function in question.