try-catch nie działa - nie łapie wyjątku

Cześć,

zmagam się od dwóch dni z nastepującym problemem.
Mam funkcję, która odczytuje jakiś tam plik z systemu plików. Podczas jednego z testów zrobiłem ten plik pusty - dostałem wtedy crasha.
Dołożyłem obsługę wyjątków try-catch w tej funkcji, bazując na backtrace, który dostałem, ale wyjątek dalej nie jest łapany.

Może ktoś rzucić okiem? Ja już się wystrzelałem z pomysłów...

Link do backtrace.

template<typename T>
std::optional<T> Database::CacheStore::read(const boost::filesystem::path& path) const
{
    boost::filesystem::ifstream file(path, std::ios_base::in | std::ios_base::binary);

    if (!file)
    {
        const std::error_code ec(errno, std::generic_category());
        // logging... 
        return std::nullopt;
    }

    T result;
    Some::Namespace::error_code ec;

    try
    {
        boost::iostreams::filtering_istream filter;
        filter.push(boost::iostreams::gzip_decompressor());
        filter.push(file);

        std::cout << "TABORET - before deserialize" << std::endl;
        ec = Signaling::Json::deserialize(filter, result);
    }
    catch (...)
    {
        std::cout << "TABORET" << std::endl;
    }

    if (ec)
    {
        // logging...
        return std::nullopt;
    }

    return result;
}

Od siebie jeszcze dodam, że trejs TABORET - before deserialize jest ostatnim przed backtrace (co też jest w nim zapisane), więc wadliwy kod jest ewidentnie obłożony try-catch.

Z góry dzięki za pomoc.

/home/.../local/CacheStore.cpp:341 która to linia kodu / jaki jest kontekst dookoła tego?

Also, od czego dostajesz crasha? SIGSEGV? SIGABRT? Coś innego? Skąd w ogóle stwierdzasz że to wyjątek leci? A jeśli tak, może rzucany jest z funkcji noexcept?

@Patryk27:
To jest ta linia ec = Signaling::Json::deserialize(filter, result);

@enedil:
Założyłem, że to wyjątek sugerując się np. std::ios_failure.
Z tego co widać z backtrace, wyjątek idzie z funkcji int std::istream::peek();, która nie jest noexcept.
Co do pytania z czego jest crash to nie potrafię odpowiedzieć. Jest handler sygnałów, ale dla tego przypadku jest handlowana grupa sygnałów (SIGILL, SIGSEGV, SIGFPE, SIGABRT) i trudno powiedzieć, który to spowodował, chyba, że czegoś nie widzę.

Najlepiej bedzie jak pokazesz co Ci wypluwa konsola konkretnie :)

EDIT: mea culpa, podales link

Nie masz opcji podpiąć się tam przez gdb? Bo z samego backtrace nie widzę jak można by cokolwiek przeanalizować.
Mam jedynie podejrzenia, że coś zamazuje pamięć zaalokowaną na wyjątek sam w sobie, i dlatego destruktor stringa (który zawiera komunikat wyjątku std::system_error) rzuca ponownie/robi std::terminate, bo gdzieś w call-chainie była funkcja noexcept/robi asserta/aborta.

Ja źle to czytam, czy exception leci z destruktora jakoś? Może po prostu robisz terminate zanim wejdziesz do catcha?

Co to za biblioteka do JSona? Google nic mi nie znajduje dla: Signaling::Json::deserialize gdzieś tam pod spodem jest rapidjson.
Crash log wskazuje na UB z tej biblioteki. Sygnał leci z destruktora std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() in /usr/lib/libstdc++.so.6
Wszystko powyżej to standardowa biblioteka i jakieś narzędzie do zbierania crash logów.