remacs panic because of a Result::unwrap()

Created on 20 Jan 2019  路  24Comments  路  Source: remacs/remacs

In a shell I run: /usr/bin/emacsclient somefile and remacs crashes.

Here the backtrace:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "\x80\xC0\xFA\xE3\u{10}V"', libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
   9: remacs::dired_unix::fnames_from_os
  10: remacs::dired_unix::directory_files_core
  11: remacs::dired_unix::directory_files_intro
  12: remacs::eval::funcall
  13: exec_byte_code
             at /data/vc/remacs/src/bytecode.c:621
  14: remacs::eval::funcall
  15: exec_byte_code
             at /data/vc/remacs/src/bytecode.c:621
  16: remacs::eval::funcall
  17: exec_byte_code
             at /data/vc/remacs/src/bytecode.c:621
  18: remacs::eval::funcall
  19: exec_byte_code
             at /data/vc/remacs/src/bytecode.c:621
  20: remacs::eval::funcall
  21: <unknown>

Backtrace:
/home/manfred/VC/remacs/src/remacs[0x502174]
/home/manfred/VC/remacs/src/remacs[0x4ea554]
/home/manfred/VC/remacs/src/remacs[0x500a5e]
/home/manfred/VC/remacs/src/remacs[0x500c58]
/home/manfred/VC/remacs/src/remacs[0x500d39]
/lib64/libpthread.so.0(+0x13030)[0x7f25bf2af030]
/lib64/libc.so.6(gsignal+0x10f)[0x7f25bee5b53f]
/lib64/libc.so.6(abort+0x127)[0x7f25bee45895]
/home/manfred/VC/remacs/src/remacs[0x6cd9a7]
/home/manfred/bin/remacs: line 3: 20271 Aborted                 (core dumped) /home/manfred/VC/remacs/src/remacs
Active PR bug
Source
picture manfredlotz

All 24 comments

I tried this

./src/remacs -q --daemon
./lib-src/remacsclient somefile

And it doesn't crash (doesn't matter if the file exists).
It also seems to work if I use /usr/bin/emacsclient which is version 26.1.

Does the above also crash for you?

krobelus picture krobelus on 20 Jan 2019

No it didn't.

In my initial post I forgot to mention that a crash doesn't happen always but once in a while.

manfredlotz picture manfredlotz on 21 Jan 2019

Well, you means that you had started a daemon in Remacs and connected to that server from system's emacsclient?

daichimukai picture daichimukai on 21 Jan 2019

Yes. Actually, I use spacemacs which starts the daemon in remacs. I often edit files by starting emacsclient from the command line.

manfredlotz picture manfredlotz on 21 Jan 2019

It seems to be due to unwrapping the result of conversion OSString to String in rust_src/src/dired_unix.rs. The reference says this will fail if non-valid Unicode data is given, so I guess dired tried to show a directory containing a file whose filename contains funny byte array.

daichimukai picture daichimukai on 21 Jan 2019

I run: /usr/bin/emacsclient --no-wait which I have defined as an alias in my shell:

Now I found a situation where it works: /usr/bin/emacsclient --no-wait fib.c

and a situation where it crashes remacs: /usr/bin/emacsclient --no-wait fib.rs

Full path of the file is: /home/manfred/tmp/fib/fib.c resp. fib.rs

manfredlotz picture manfredlotz on 21 Jan 2019

Very interesting: If I try to load fib.rs from within remacs it is crashing as well.

manfredlotz picture manfredlotz on 21 Jan 2019

Here is the trace when I load fib.rs with find-file-at-point 

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "\x80\xC0\xFA\xE3\u{10}V"', libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:476
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
   9: remacs::dired_unix::fnames_from_os
  10: remacs::dired_unix::directory_files_core
  11: remacs::dired_unix::directory_files_intro
  12: remacs::eval::funcall
  13: exec_byte_code
             at /data/vc/remacs/src/bytecode.c:621
  14: remacs::eval::funcall
  15: exec_byte_code
             at /data/vc/remacs/src/bytecode.c:621
  16: remacs::eval::funcall
  17: exec_byte_code
             at /data/vc/remacs/src/bytecode.c:621
  18: remacs::eval::funcall
  19: exec_byte_code
             at /data/vc/remacs/src/bytecode.c:621
  20: remacs::eval::funcall
  21: <unknown>

Backtrace:
/home/manfred/VC/remacs/src/remacs[0x502154]
/home/manfred/VC/remacs/src/remacs[0x4ea534]
/home/manfred/VC/remacs/src/remacs[0x500a3e]
/home/manfred/VC/remacs/src/remacs[0x500c38]
/home/manfred/VC/remacs/src/remacs[0x500d19]
/lib64/libpthread.so.0(+0x13030)[0x7f8a21dfa030]
/lib64/libc.so.6(gsignal+0x10f)[0x7f8a219a653f]
/lib64/libc.so.6(abort+0x127)[0x7f8a21990895]
/home/manfred/VC/remacs/src/remacs[0x6cd897]
/home/manfred/bin/remacs: line 3:  6374 Aborted                 (core dumped) /home/manfred/VC/remacs/src/remacs
manfredlotz picture manfredlotz on 21 Jan 2019

"\x80\xC0\xFA\xE3\u{10}V"

What is that? Is that in the directory names?

shaleh picture shaleh on 21 Jan 2019

I have no idea what that is. The directory of fib.rs is actually /home/manfred/tmp/fib

manfredlotz picture manfredlotz on 21 Jan 2019

Ok, please launch remacs with -Q so it does not load your config. Then try again. Does it still crash? If not, please bisect your config so we can identify where the trigger is coming from.

Thank you!

shaleh picture shaleh on 21 Jan 2019

I think I found the cause of it.

In my home directory there was a directory with an unreadable name:
/home/manfred/''$'\200\300\372\343\020''V' which seems to be a match for "\x80\xC0\xFA\xE3\u{10}V"

Then in directory /home/manfred/tmp/fib loading of files fib.go aso caused remacs to crash. Loading of files fib.c, fib.darts etc didn't.

I think remacs shouldn't crash if there is a bad directory name at some place in the file hierarchy.

manfredlotz picture manfredlotz on 21 Jan 2019
👍1

Agreed. Feel up to improving the dired test suite?

shaleh picture shaleh on 21 Jan 2019

I'm not sure I know exactly what to do.

manfredlotz picture manfredlotz on 21 Jan 2019

Do help narrow this down a test which creates a directory like yours and calls dired against it will help. Initially it will fail and we can fix it.

shaleh picture shaleh on 21 Jan 2019

I will try.

One question: if I test for the outcome of make-directory what kind of should function do I use to test for a succesful make-directory call? The point it that make-directory doesn't seem to give a result to check for.

manfredlotz picture manfredlotz on 21 Jan 2019

Aah, sorry. I just see I have to call dired against the created directory... Ok, will see.

manfredlotz picture manfredlotz on 21 Jan 2019

I am stuck. First of all, it is hard to find a test case which crashes.

If I try something like this:

(ert-deftest dired-test-bug1267 ()
  "Test for https://github.com/Wilfred/remacs/issues/1267 ."
  (let* ((dir "\x80\xC0\xFA\xE3\x10V" ))
    (unwind-protect
        (progn
          (make-directory dir)
          (should (setq buf (dired dir)))
          (delete-directory dir 'recursive)
          ))))

then delete-directory doesn't happen. Don't know why.

I inserted the test function in direc-x-tests.el.

manfredlotz picture manfredlotz on 22 Jan 2019

Thanks for looking. The error is likely in dired_unix.rs:read_dir. We may be able to write Rust unit tests directly.

shaleh picture shaleh on 22 Jan 2019

https://github.com/Wilfred/remacs/blob/1aeddfaba0c4f76c70521430fd61031adad47898/rust_src/src/dired_unix.rs#L247 is the likely culprit. But there are plenty of other unchecked unwrap calls in there. The project should try to add more testing.

shaleh picture shaleh on 22 Jan 2019

If you replace that line with:

let f_enc = match fname.file_name().into_string() {
    Ok(v) => v,
    Err(original) => { error!("Unhandled string conversion in read_dir: {}", original); },
};

I am willing to bet the error changes to the above message instead of a panic on unwrap.
If so, the right thing to do is to unpack the Err and create a new io::Result::Err in its place instead of the existing unwrap call.

Yes, an unwrap_or_else would work here. The match makes it easier to investigate with a debugger.

shaleh picture shaleh on 22 Jan 2019

Does #1275 work better for you? Or does the error move to another operation?

shaleh picture shaleh on 22 Jan 2019

Thanks for the fix.

I remade remacs using your fix #1275 . No more crash.

In the Messages buffer I see now:
File mode specification error: (file-missing Opening directory: Could not decode "\x80\xC0\xFA\xE3\u{10}V" /home/manfred/) [2 times]

manfredlotz picture manfredlotz on 23 Jan 2019
🎉1

To avoid confusion: [2 times] came from me trying it out two times. So actually the message came only one time as it should be.

manfredlotz picture manfredlotz on 23 Jan 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

PythonNut picture PythonNut  路  3Comments
DavidDeSimone picture DavidDeSimone  路  6Comments
MarcusE1W picture MarcusE1W  路  5Comments
brotzeit picture brotzeit  路  5Comments
brotzeit picture brotzeit  路  3Comments