46: regex error 17 for `(dryad-bibo/v)[0-9].[0-9]', (match failed)

Question

I'm trying to determine the mime-type for several types of files using libmagic and the following bit of code:

auto handle = ::magic_open(MAGIC_MIME_TYPE);
::magic_load(handle, NULL);

// Both of these fail with the same error
// file_path being a const char* with the path to the file.
auto type2 = ::magic_file(handle, file_path);

// svg_content being an std::vector<char> with the contents of the file.
//auto type2 = ::magic_buffer(handle, svg_content.data(), svg_content.size()); 

if(!type2)
{
   std::cout << magic_error(handle) << std::endl;
}
    
::magic_close(handle);

But for any file or buffer I try I receive regex error, either being or similar to:

46: regex error 17 for `(dryad-bibo/v)[0-9].[0-9]', (match failed)

For example with this .svg file:

<svg xmlns="http://www.w3.org/2000/svg" id="flag-icon-css-no" viewBox="0 0 640 480">
  <path fill="#ed2939" d="M0 0h640v480H0z"/>
  <path fill="#fff" d="M180 0h120v480H180z"/>
  <path fill="#fff" d="M0 180h640v120H0z"/>
  <path fill="#002664" d="M210 0h60v480h-60z"/>
  <path fill="#002664" d="M0 210h640v60H0z"/>
</svg>

What I've tried so far:

• libmagic 5.35
• libmagic 5.39
• libmagic 5.40
• libmagic from opensource.apple
• setting LC_TYPE and LANG to "C"

I'm linking against a version of libmagic that was built locally, could there be anything I have missed while building? Are any of the calls incorrect or is there something I'm missing?

I get similar errors when trying to run the related file binary that was compiled locally. Whereas when I use the file command that is available by default I do get image/svg+xml as output.

Edit

To build libmagic (for macOS and Ubuntu), I followed these steps:

• Downloaded relevant release from Github
• autoreconf --install
• ./configure
• make
• make install

Update

It looks like the regex at the bottom of this file is causing issues (at least for the svg):

https://github.com/file/file/blob/b56b58d499dbe58f2bed28e6b3c297fe7add992e/magic/Magdir/dataone

Update 2

Something strange going on; On the system where I've got it working, magic_version() reports 540, as expected. But on the systems where it fails with this error, magic_version() reports 538.

This makes little sense to me as I can't find that version on the system itself anywhere and when I run ./file --version in the build library, it reports file-5.40.

Answer 1

Very dissatisfying answer, but it was linking against GoogleTest causing this error somehow, not even running any tests, just linking against it.

I switched to using Catch2 instead and the issue was resolved.

Answer 2

Tested on Ubuntu 20.04.:

Clone the repo

git clone git@github.com:file/file.git
cd file/

Try this in fresh clone of the repo:

autoreconf -f -i
./configure --disable-silent-rules
make -j4
make -C tests check

And see whether there are any errors reported. After installation with make install, grab some valid xml file named as "test.xml" and put it to some folder together with this main.c:

#include <stdio.h>
#include <magic.h>

int main(void)
{
    char *actual_file = "test.xml";
    const char *magic_full;
    magic_t magic_cookie;

    /* MAGIC_MIME tells magic to return a mime of the file,
       but you can specify different things */
    magic_cookie = magic_open(MAGIC_MIME);

    if (magic_cookie == NULL) {
        printf("unable to initialize magic library\n");
        return 1;
    }

    printf("Loading default magic database\n");

    if (magic_load(magic_cookie, NULL) != 0) {
        printf("cannot load magic database - %s\n", magic_error(magic_cookie));
        magic_close(magic_cookie);
        return 1;
    }

    magic_full = magic_file(magic_cookie, actual_file);
    printf("%s\n", magic_full);
    magic_close(magic_cookie);
    return 0;
}

(Courtesy to vivithemage.)

Compile and try:

$ gcc main.c -lmagic
$ ./a.out 
Loading default magic database
text/xml; charset=us-ascii

If it does not work on your system, report bug on project's bugtracker with specification of your OS and architecture. You can try to hotfix your problem by removing offending record from the file you have found in your update.