2

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.

  • This thread on the emacs-devel mailing list suggests that it's a problem with browse-url. – Dan Dec 17 '14 at 15:33
  • Yeah, I read that thread, but I don't know how to correlate it to what I'm seeing. browse-url doesn't show up in the stacktrace, although a lot of url-http and url-open-stream stuff does. – abingham Dec 17 '14 at 15:50
  • @abingham this seems like a pretty obscure bug. Your best bet is to offer your feedback on that thread. – Malabarba Dec 18 '14 at 12:03
  • You're probably right. I posted a question to that list already, but I've yet to receive a response. – abingham Dec 18 '14 at 12:21
  • Would you like to post the stack trace? It may help, and it will increase the googlability of anyone else who encounters the same issue. – Wilfred Hughes Dec 20 '14 at 10:37
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.