Isctype c ошибка

Сегодня мне пришел баг-репорт от пользователя Debian, который скормил какую-то ерунду в утилиту scdoc и получил SIGSEGV. Исследование проблемы позволило мне провести отличное сравнение между musl libc и glibc. Для начала посмотрим на стектрейс:

==26267==ERROR: AddressSanitizer: SEGV on unknown address 0x7f9925764184
(pc 0x0000004c5d4d bp 0x000000000002 sp 0x7ffe7f8574d0 T0)
==26267==The signal is caused by a READ memory access.
    0 0x4c5d4d in parse_text /scdoc/src/main.c:223:61
    1 0x4c476c in parse_document /scdoc/src/main.c
    2 0x4c3544 in main /scdoc/src/main.c:763:2
    3 0x7f99252ab0b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
    4 0x41b3fd in _start (/scdoc/scdoc+0x41b3fd)

В исходниках на данной строчке написано вот что:

if (!isalnum(last) || ((p->flags & FORMAT_UNDERLINE) && !isalnum(next))) {

Подсказка: p — это корректный, ненулевой указатель. Переменные last и next имеют тип uint32_t. Сегфолт случается на втором вызове функции isalnum. И, самое важное: воспроизводится только при использовании glibc, но не musl libc. Если вам пришлось перечитать код несколько раз, вы не одиноки: тут попросту нечему вызывать сегфолт.

Поскольку было известно, что все дело в библиотеке glibc, я достал ее исходники и стал искать реализацию isalnum, готовясь столкнуться с какой-нибудь дурацкой фигней. Но прежде чем я дойду до дурацкой фигни, которой там, уж поверьте, навалом, давайте сначала быстренько поглядим на хороший вариант. Вот так функция isalnum реализована в musl libc:

int isalnum(int c)
{
	return isalpha(c) || isdigit(c);
}

int isalpha(int c)
{
	return ((unsigned)c|32)-'a' < 26;
}

int isdigit(int c)
{
	return (unsigned)c-'0' < 10;
}

Как и ожидалось, для любого значения c функция отработает без сегфолта, потому что с какого хрена вообще isalnum должна кидать сегфолт?

Ладно, теперь сравним это с реализацией glibc. Как только вы откроете заголовок, вас будет встречать типичная GNU’шная галиматья, но пропустим ее и попытаемся найти isalnum.

Первый результат такой:

enum
{
  _ISupper = _ISbit (0),        /* UPPERCASE.  */
  _ISlower = _ISbit (1),        /* lowercase.  */
  // ...
  _ISalnum = _ISbit (11)        /* Alphanumeric.  */
};

Похоже на деталь реализации, двигаемся дальше.

__exctype (isalnum);

Но что такое __exctype? Возвращаемся на несколько строчек вверх…

#define __exctype(name) extern int name (int) __THROW

Ладно, по всей видимости это только прототип. Непонятно правда, зачем тут нужен макрос. Ищем дальше…

#if !defined __NO_CTYPE
# ifdef __isctype_f
__isctype_f (alnum)
// ...

Так, вот это уже похоже на что-то полезное. Что такое __isctype_f? Мотаем вверх…

#ifndef __cplusplus
# define __isctype(c, type) 
  ((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type)
#elif defined __USE_EXTERN_INLINES
# define __isctype_f(type) 
  __extern_inline int                                                         
  is##type (int __c) __THROW                                                  
  {                                                                           
    return (*__ctype_b_loc ())[(int) (__c)] & (unsigned short int) _IS##type; 
  }
#endif

Ну начинается… Ладно, вместе как-нибудь разберемся. Видимо, __isctype_f — это инлайн-функция… стоп, это все находится внутри блока else препроцессорной инструкции #ifndef __cplusplus. Тупик. Где же isalnum, мать ее, на самом деле определена? Ищем дальше… Может вот оно?

#if !defined __NO_CTYPE
# ifdef __isctype_f
__isctype_f (alnum)
// ...
# elif defined __isctype
# define isalnum(c)     __isctype((c), _ISalnum) // <- вот тут

Эй, это же «деталь реализации», которую мы видели раньше. Помните?

enum
{
  _ISupper = _ISbit (0),        /* UPPERCASE.  */
  _ISlower = _ISbit (1),        /* lowercase.  */
  // ...
  _ISalnum = _ISbit (11)        /* Alphanumeric.  */
};

Попробуем по-быстрому расковырять этот макрос:

# include <bits/endian.h>
# if __BYTE_ORDER == __BIG_ENDIAN
#  define _ISbit(bit)   (1 << (bit))
# else /* __BYTE_ORDER == __LITTLE_ENDIAN */
#  define _ISbit(bit)   ((bit) < 8 ? ((1 << (bit)) << 8) : ((1 << (bit)) >> 8))
# endif

Ну что за фигня? Ладно, двигаем дальше и считаем, что это просто магическая константа. Другой макрос называется __isctype, который похож на недавно виденный нами __isctype_f. Посмотрим еще разок на ветку #ifndef __cplusplus:

#ifndef __cplusplus
# define __isctype(c, type) 
  ((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type)
#elif defined __USE_EXTERN_INLINES
// ...
#endif

Эээ…

Ну, по крайней мере мы нашли разыменовывание указателя, которое могло бы объяснить сегфолт. А что такое __ctype_b_loc?

/* Эти объявления находятся в файле ctype-info.c.
   Они должны совпадать с объявлениями в файле localeinfo.h.

   В модели локалей, основывающейся на потоках, (см. `uselocale' в <locale.h>)
   мы не можем пользоваться глобальными переменными, как раньше.
   Вместо этого, ниже указаны функции-аксессоры, которые возвращают адрес
   каждой переменной, относящейся к текущему потоку, если потоков несколько.

   Они указывают на массивы из 384 элементов, поэтому для индексации можно
   использовать значение `unsigned char' [0,255]; а также EOF (-1); или любое
   значение `signed char' value [-128,-1).  ISO C требует, чтобы функции ctype работали
   со значениями типа `unsigned char' и EOF; мы также поддерживаем отрицательные
   значения `signed char' для совместимости со старыми некорректными программами.
   Массивы для конвертации регистра содержат значения типа `int`,
   а не `unsigned char`, потому что `tolower(EOF)' должно возвращать EOF, а это значение
   не помещается в диапазон `unsigned char`. Однако сейчас самое важное - то, что
   эти массивы также используются для многобайтовых кодировок.  */
extern const unsigned short int **__ctype_b_loc (void)
     __THROW __attribute__ ((__const__));
extern const __int32_t **__ctype_tolower_loc (void)
     __THROW __attribute__ ((__const__));
extern const __int32_t **__ctype_toupper_loc (void)
     __THROW __attribute__ ((__const__));

Как круто с твоей стороны, glibc! Я просто обожаю иметь дело с локалями. Так или иначе, к моему упавшему приложению подключен gdb, и держа в уме всю полученную информацию я пишу вот это убожество:

(gdb) print ((unsigned int **(*)(void))__ctype_b_loc)()[next]
Cannot access memory at address 0x11dfa68

Сегфолт найден. В комменте была про это строчка: «ISO C требует, чтобы функции ctype работали со значениями типа `unsigned char’ и EOF». Если найти это в спецификации, увидим:

Во всех реализациях [функций, объявленных в ctype.h], аргументом является int, значение которого должно помещаться в unsigned char, или же равняться значению макроса EOF.

Теперь становится очевидно, как исправить проблему. Мой косяк. Оказывается, я не могу скормить в isalnum произвольный символ UCS-32 для проверки на его вхождение в диапазоны 0x30-0x39, 0x41-0x5A и 0x61-0x7A.

Но тут я возьму на себя смелость предположить: а может быть, функция isalnum вообще не должна кидать сегфолт, вне зависимости от того, что ей передадут? Может быть, даже если спецификация это разрешает, это не означает, что так надо делать? Может быть, ну просто в качестве безумной идеи, поведение этой функции не должно содержать пять макросов, проверять использование компилятора C++, зависеть от порядка байтов вашей архитектуры, таблицы поиска, данных о локали потока и разыменовывать два указателя?

Еще разок посмотрим на версию в musl в качестве быстрого напоминания:

int isalnum(int c)
{
	return isalpha(c) || isdigit(c);
}

int isalpha(int c)
{
	return ((unsigned)c|32)-'a' < 26;
}

int isdigit(int c)
{
	return (unsigned)c-'0' < 10;
}

Вот такие пироги.

Примечание переводчика: спасибо MaxGraey за ссылку на оригинал.

Ваше мнение

Проголосовали 464 пользователя.

Воздержались 75 пользователей.

bool isctype( CharT c, char_class_type f ) const;

Determines whether the character c belongs to the character class identified by f, which, in turn, is a value returned by lookup_classname() or a bitwise OR of several such values.

The version of this function provided in the standard library specializations of std::regex_traits does the following:

1) First converts f to some temporary value m of type std::ctype_base::mask in implementation-defined manner

2) Then attempts to classify the character in the imbued locale by calling std::use_facet<std::ctype<CharT>>(getloc()).is(m, c). If that returned true, true is returned by isctype().

3) Otherwise, checks whether c equals '_' and the bitmask f includes the result of calling lookup_classname() for the character class [:w:], in which case true is returned.

4) Otherwise, false is returned.

Parameters

Return value

true if c is classified by f, false otherwise.

Notes

The description above summarizes C++14; the C++11 phrasing required this function to return true for '_' in all cases (LWG issue 2018).

Example

#include <iostream>
#include <string>
#include <regex>
 
int main()
{
    std::regex_traits<char> t;
    std::string str_alnum = "alnum";
    auto a = t.lookup_classname(str_alnum.begin(), str_alnum.end());
    std::string str_w = "w"; // [:w:] is [:alnum:] plus '_'
    auto w = t.lookup_classname(str_w.begin(), str_w.end());
    std::cout << std::boolalpha
              << t.isctype('A', w) << ' ' << t.isctype('A', a) << 'n'
              << t.isctype('_', w) << ' ' << t.isctype('_', a) << 'n'
              << t.isctype(' ', w) << ' ' << t.isctype(' ', a) << 'n';
}

true true
true false
false false

#include <iostream>
#include <locale>
#include <regex>
#include <cwctype>
 
// This custom regex traits uses wctype/iswctype to implement lookup_classname/isctype
struct wctype_traits : std::regex_traits<wchar_t>
{
    using char_class_type = std::wctype_t;
    template<class It>
    char_class_type lookup_classname(It first, It last, bool=false) const {
        return std::wctype(std::string(first, last).c_str());
    }
    bool isctype(wchar_t c, char_class_type f) const {
        return std::iswctype(c, f);
    }
};
 
int main()
{
    std::locale::global(std::locale("ja_JP.utf8"));
    std::wcout.sync_with_stdio(false);
    std::wcout.imbue(std::locale());
 
    std::wsmatch m;
    std::wstring in = L"風の谷のナウシカ";
    // matches all characters (they are classified as alnum)
    std::regex_search(in, m, std::wregex(L"([[:alnum:]]+)"));
    std::wcout << "alnums: " << m[1] << 'n'; // prints "風の谷のナウシカ"
    // matches only the katakana
    std::regex_search(in, m,
                      std::basic_regex<wchar_t, wctype_traits>(L"([[:jkata:]]+)"));
    std::wcout << "katakana: " << m[1] << 'n'; // prints "ナウシカ"
}

alnums: 風の谷のナウシカ
katakana: ナウシカ

See also

Thread: Assertion Failure

I’ve been trying to use cv::VideoCapture::open(«< path to video file >») in QtCreator (opencv added). Even though the program runs without errors in «bebug mode» (debug build), it gives below runtime error in «release mode» (release build).

Debug Assertion Failed File:
f:/dd/vctools/crt_bld/self_x86/src/isctype.c Line: 56 Expression:
(unsigned)(c+1) <= 256

It is a simple program which uses only cv::VideoCapture::open() [for testing purposes]

Below is the .pro file

QT       += core gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = untitled
TEMPLATE = app
SOURCES += main.cpp
        mainwindow.cpp   
HEADERS  += mainwindow.h   
FORMS    += mainwindow.ui   

INCLUDEPATH += C:/C/opencv/build/include
INCLUDEPATH += C:/C/opencv/build/include/opencv  

LIBS += C:/C/opencv/build/x86/vc10/lib/opencv_highgui240d.lib
LIBS += C:/C/opencv/build/x86/vc10/lib/opencv_highgui240.lib


LIBS += C:/C/opencv/build/x86/vc10/bin/opencv_highgui240d.dll
LIBS += C:/C/opencv/build/x86/vc10/bin/opencv_highgui240.dll

Below is the Header file

#include <QMainWindow>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/core/core.hpp>

namespace Ui {
class MainWindow;
}

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    explicit MainWindow(QWidget *parent = 0);
    ~MainWindow();

private:
    Ui::MainWindow *ui;
    cv::VideoCapture vcap;
};

Below is the .cpp file

#include "mainwindow.h"
#include "ui_mainwindow.h"

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
    vcap.open("C:/Users/ANURUDDHA/pedestrians/ThreePastShop2cor.mpg");
}

MainWindow::~MainWindow()
{
    delete ui;
}

When I pass an int as the argument to cv::VideoCapture::open() [eg: vcap.open(0)] it runs without errors in both debug and release build and opens webcam successfully. Problem comes only when I pass a String to arguments.

Someone please shed some light on this. Really appreciated.

I’ve been trying to use cv::VideoCapture::open(«< path to video file >») in QtCreator (opencv added). Even though the program runs without errors in «bebug mode» (debug build), it gives below runtime error in «release mode» (release build).

Debug Assertion Failed File:
f:/dd/vctools/crt_bld/self_x86/src/isctype.c Line: 56 Expression:
(unsigned)(c+1) <= 256

It is a simple program which uses only cv::VideoCapture::open() [for testing purposes]

Below is the .pro file

QT       += core gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = untitled
TEMPLATE = app
SOURCES += main.cpp
        mainwindow.cpp   
HEADERS  += mainwindow.h   
FORMS    += mainwindow.ui   

INCLUDEPATH += C:/C/opencv/build/include
INCLUDEPATH += C:/C/opencv/build/include/opencv  

LIBS += C:/C/opencv/build/x86/vc10/lib/opencv_highgui240d.lib
LIBS += C:/C/opencv/build/x86/vc10/lib/opencv_highgui240.lib


LIBS += C:/C/opencv/build/x86/vc10/bin/opencv_highgui240d.dll
LIBS += C:/C/opencv/build/x86/vc10/bin/opencv_highgui240.dll

Below is the Header file

#include <QMainWindow>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/core/core.hpp>

namespace Ui {
class MainWindow;
}

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    explicit MainWindow(QWidget *parent = 0);
    ~MainWindow();

private:
    Ui::MainWindow *ui;
    cv::VideoCapture vcap;
};

Below is the .cpp file

#include "mainwindow.h"
#include "ui_mainwindow.h"

MainWindow::MainWindow(QWidget *parent) :
    QMainWindow(parent),
    ui(new Ui::MainWindow)
{
    ui->setupUi(this);
    vcap.open("C:/Users/ANURUDDHA/pedestrians/ThreePastShop2cor.mpg");
}

MainWindow::~MainWindow()
{
    delete ui;
}

When I pass an int as the argument to cv::VideoCapture::open() [eg: vcap.open(0)] it runs without errors in both debug and release build and opens webcam successfully. Problem comes only when I pass a String to arguments.

Someone please shed some light on this. Really appreciated.