Eval bug: Crash with filesystem error when run while in a directory containing files with certain names

[ScarletEmerald]

Name and Version

version: 4462 (c05e8c9)
built with cc (Debian 12.2.0-14) 12.2.0 for x86_64-linux-gnu

Operating systems

Linux

GGML backends

CPU

Hardware

N/A

Models

N/A

Problem description & steps to reproduce

Running llama-cli or llama-server while the current directory contains a file with certain characters in the file name causes a crash with the filesystem error shown below.

Here is an example of a character that will cause the crash when present in a file name
｜

First Bad Commit

commit 60cfa72

Relevant log output

terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: Cannot convert character sequence: Invalid or incomplete multibyte or wide character
Aborted

[slaren]

I cannot reproduce this. What call causes the exception?

[ScarletEmerald]

Looks like it is this line

https://github.com/ggerganov/llama.cpp/blob/c05e8c9934f94fde49bc1bc9dc51eed282605150/ggml/src/ggml-backend-reg.cpp#L511

0x000055555579ff42 in ggml_backend_load_best (name=0x5555558b6dbd "blas",
silent=false, user_search_path=0x0)
at [...]/lama.cpp/ggml/src/ggml-backend-reg.cpp:511

[slaren]

From what I can tell, this is a bug in gcc that should already be fixed. I cannot reproduce it on my system with gcc 12.3 or 13.3. I will try to find a workaround for older versions, but updating should fix your issue.

[gnusupport]

# go to safe directory to avoid https://github.com/ggml-org/llama.cpp/issues/11198

mkdir -p /tmp/safe/llm
cd /tmp/safe/llm

I do that now.

[clort81]

I am getting this, and also in python programs: sequence item 0: expected str instance, bytes found

But i can't tell when. Locale is en UTF8 hasn't changed. No non-ascii appears in filepaths.
The problem comes and goes at will.

[SebastianSchiefer]

I was having the same issue and for me it happened as long as this file with a weird name existed in the path i tried to launch llama-server from:

sebis@sebis-MS-7C35:~$ ls -la
total 1604
drwxr-x--- 26 sebis sebis     4096 Feb 28 13:03  .
drwxr-xr-x  3 root  root      4096 Dec 15 14:14  ..
-rw-rw-r--  1 sebis sebis        0 Feb 27 11:08 ''$'\001\307\037\001''@'$'\020\260\016''@8'
...

After deleting this file, llama-server starts normally again!

The existence of this file had nothing to do with llama.cpp for me, it was created after i used llama-server the last time. It looks like the file was created yesterday around the time when i reinstalled Pycharm and launched it from terminal to test if my executable in /bin for launching it worked. Not sure what caused the creation of this file, i cannot reproduce it.

@slaren
My gcc-version is 13.3.0, so it should not be the bug you linked causing this issue, in my opinion:

sebis@sebis-MS-7C35:~$ gcc --version
gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0

[slaren]

@SebastianSchiefer thanks, that file name allowed me to reproduce the issue.

#12144 should fix it.

[clort81]

Based on some suggestions of people here i test wither the crash is triggered by invalid utf-8 filenames in the $PATH

#!/bin/bash
# create an invalid utf-8 filename some where in your $PATH
#  touch $'\xff\xfe'
#
# Split the PATH variable into individual directories
IFS=: read -r -a path_dirs <<< "$PATH"

# Iterate through each directory in the PATH
for dir in "${path_dirs[@]}"; do
  # Check if the directory exists and is readable
  if [ -d "$dir" ] && [ -r "$dir" ]; then
    # Find files with non-UTF8 names in the current directory
    find "$dir" -type f -print0 | while IFS= read -r -d '' file; do
      my_iconv_res=$(iconv -f UTF-8 -t UTF-8 <<< "$file" 2>/dev/null)
      if [ $? -ne 0 ]; then
        echo "Non-UTF8 filename: $file"
      fi
    done
  else
    echo "${dir} Skipping unreadable directory."
  fi
done

In my case this identifies the created 'bad file', but none other in my $PATH.

However slaren's fix fixed it for me!

Thank you sir, I am in your debt.