Called 'Option::unwrap()' on a 'None' in minibuffer.

[jaccarmac]

My init.el

Packages that may have something to do with the error are golden-ratio, ido-everywhere, ido-completing-read+, or switch-window.

[shaleh]

Fun. (propertize) is the likely candidate from editfns.rs. Perhaps you could add some debugging there and try again. All of the other unwrap calls I see are protected with unwrap_or_else or similar.

[jaccarmac]

Thanks for the investigation, I'll take a look.

[shaleh]

This reminds me of a need that (r)emacs has. There should be a simple, obvious way to say "start emacs with this config". Something like --with-init /path/to/init and /path/to/init can either be a emacs.d or init.el or any other valid initialization file/dir. The editor should set whatever variables it needs for that directory (if it is one) to be the directory everything is searched in.

[jaccarmac]

This bug seems to actually be in region_limit.

[shaleh]

hmmm, ok. That is not entirely what I expected from the messages in your screen shot. But the error message is there. We all wait for the next installment......

[jaccarmac]

Yeah, this is turning out to be quite bizarre. I'm a bit confused by the minbuffer output when adding println!s, do we catch panic! somewhere up above?

[jaccarmac]

Essentially, I really need a way to get the full error output instead of what seems like terminal output interspersed with actual minibuffer messages.

[shaleh]

I usually load the editor in a debugger once I know where the issue is. A useful hack is to duplicate the Rust function and rename it. Then you can control when and how it is called. The file etc/DEBUG in the tree has some further tips and tricks from long time Emacs hackers.

Also, try eprintln! which goes to stderr, it might work better.

[jaccarmac]

I'm still getting terminal output when I explicitly request it, the issue is that the panic messages are getting caught and squashed by other minibuffer output.

[cantsin]

Took a quick look at this, using the most recent commit as of today. I can't seem to replicate this bug. I can only trigger this error if I explicitly invoke the relevant lisp code (region-beginning) in a newly visited buffer (although the debugger comes up instead of the error being echoed in the minibuffer).

I also get the following errors when I load the given init.el file, since my system isn't configured as the init file expects:

Error (use-package): edit-server/:config: Process edit-server does not exist
Warning (emacs): [EXWM] EXWM fails to start (error: (Other window manager is running))

So maybe the issue is with one of the above libraries (but I doubt it).

For the record, I invoked remacs like so:

./remacs -Q --eval '(progn (setq user-emacs-directory "/home/james/remacs-build/1498/" user-init-file "/home/james/remacs-build/1498/init.el") (load user-init-file))'

[jaccarmac]

Thanks for checking it out. Those errors are in fact benign.

How did you determine the root cause as being region-beginning?

In any case, I'm seeing an error, albeit less of one. Now the visible part of the error I see is just src/numbers.rs. Real weird stuff, and I'm not sure what changed between the last time I built and now.

[jaccarmac]

Since I didn't include repro steps in the original issue this is what I'm doing.

1. Open up Emacs with my init file (the most recent version from my Fossil repo might be easier to deal with as it doesn't give as many messages on startup).
2. Split the scratch buffer with C-x 3 or equivalent.
3. Open up the minibuffer with M-x.
4. Try to switch buffers with C-x o.

[cantsin]

Oh, interesting, as soon as I try to split the scratch buffer I see the error with numbers.rs you allude to:

Right-split window: attempted to derefence an uninitialized lazy static. This is a bug/home/james/.cargo/registry/src/github.com-1ecc6299db9ec823/lazy_static-1.2.0/src/inline_lazy.rssrc/numbers.rs

(sic, typos and missing spaces are part of the above error message)

Same error happens if I try to delete a window or move to a window. The only lazy static I see in numbers.rs is this bit:

lazy_static! {
    static ref RNG: Mutex<StdRng> = Mutex::new(StdRng::from_entropy());
}

But that's only used for the (random &optional LIMIT) function, which doesn't seem relevant here. In any case, (split-window-right) works, whereas (switch-window-then-split-right 1) doesn't. Maybe something in switch-window.el?

In any case, I agree that perhaps the more fundamental bug is that these error messages are being dropped silently. These errors do not show up in *Warnings* or *Messages*, and M-x toggle-debug-on-error does nothing.

[jaccarmac]

There seems to be a common thread here of bizarre error messages that seem to be pointing to the wrong part of the source, and the stream for that error being eaten by the minibuffer. Not totally sure how to make Remacs really panic and give me the whole stacktrace, so I may have to venture into GDB-land, where I was loath to poke my head before.

In any case thanks for all the help corroborating.

[shaleh]

Possibilities:

• when switch-windo--then tries to run the hooks at the end
• when the window list is retrieved?

[shaleh]

re: Rust traces:

RUST_BACKTRACE=1 needs to be set in the environment. Configure with --enable-rust-debug.

Add liberal asserts or panic! to the code.

[shaleh]

On linux, learn to use https://rr-project.org/. It is super helpful. On OSX I find lldb to give better answers.

[cantsin]

For the record, fixing some font bugs makes this error message change (see #1512). Now I'm getting Right-split window: ^Ofailed to fill whole buffer. (sic again -- not sure where ^O is coming from) I'm not sure if this is an improvement or not...

In any case, I think I know why these error messages aren't showing up anywhere. They are coming along with special events which are explicitly never echoed: https://www.gnu.org/software/emacs/manual/html_node/elisp/Special-Events.html#Special-Events -- I did not know about these, this is new to me. So the following diff makes these messages show up. (Not a fix, this is just so I can finally see these errors in *Messages*.)

@@ -367,7 +367,7 @@ pub fn read_event(
     seconds: LispObject,
 ) -> LispObject {
     if !prompt.is_nil() {
-        message_with_string!("%s", prompt, false);
+        message_with_string!("%s", prompt, true);
     }
 
     unsafe { read_filtered_event(false, false, false, !inherit_input_method.is_nil(), seconds) }

Also, on a tangential note, I can't seem to get Emacs' src/.gdbinit to work with rr (very likely I'm doing something wrong, maybe this is not supported?). I'm getting Attempt to write memory outside diversion session and CHECK_LISP_OBJECT_TYPE not set errors. Remacs is currently configured with with --enable-rust-debug --enable-checking='yes,glyphs' --enable-check-lisp-object-type.

[db48x]

Attempt to write memory outside diversion session and CHECK_LISP_OBJECT_TYPE not set errors.

I've run into this before. In order to preserve the correct replay behavior, rr must prevent the state of the program from diverging from the recording. Thus, any gdb command which writes to memory (or might do so), needs to be coerced into writing to freshly-allocated memory which can then be thrown away after the command is done. That's the "diversion area" that the error mentions.

In this case, the alias that pretty-prints things is setting the print_output_debug_flag global variable to a default value, calling safe_debug_print, and then setting the variable back. I believe that the fix was to change the pp alias to call debug_output_compilation_hack(0) instead to set the value. Obviously that's not this function's original purpose, but it does exactly what we need.

I'm sure I had fixed this in my .gdbinit file, and I thought I had committed the fix. Either way, here's my conversation with roc on the subject:

[10:23]          <db48x> roc: I've been meaning to ask if you can help me with a minor rr problem
                 <db48x> I'm trying to pretty-print a lisp structure while in the debugger
                 <db48x> there's a helper that does it, but it generates an error
                 <db48x> (rr) pp fun[ERROR /home/db48x/src/rr/rr/src/GdbServer.cc:518:dispatch_debugger_request()] Attempt to write memory outside
                         diversion session
                 <db48x> Cannot access memory at address 0x14b27d8
                 <db48x> if I instead directly call the C function that does the printing it'll work fine
                 <db48x> (rr) p safe_debug_print(fun)
                 <db48x> (lambda (x y) (< x y))
[10:25]          <db48x> https://pastebin.mozilla.org/9087054
                   <roc> db48x: maybe use RR_LOG=GdbServer,GdbConnection and figure it out
[16:22]          <db48x> roc: https://pastebin.mozilla.org/9087085
[16:26]            <roc> what's at adress 0x14b27d8 ?
[16:28]          <db48x> ah, that's the variable print_output_debug_flag
                   <roc> ok
                   <roc> you can't just set that outside a function call
[16:29]            <roc> but if you wrap the setting of it in a function call, that should work
[16:30]          <db48x> heh, what do you know:
                 <db48x> /* This function is never called.  Its purpose is to prevent
                 <db48x>    print_output_debug_flag from being optimized away.  */
                 <db48x> extern void debug_output_compilation_hack (bool) EXTERNALLY_VISIBLE;
[16:36]          <db48x> roc: thanks :)
[16:47]          <db48x> roc: so when exactly does rr discard the diversion session? after every function call?
                   <roc> when you continue not in a function call
[16:48]          <db48x> cool, several functions called in sequence all operate out of the same session
[16:49]                * db48x adds some notes to the shared .gdbinit