Re: [devel] armh + libjpeg + c++ exceptions

[Alexey Sheplyakov <asheplyakov@basealt.ru>]

Добрый вечер!

On 6/23/20 1:49 PM, Vladislav Zavjalov wrote:

> В библиотеках C иногда используются callback'и,
> и туда легко могут попасть исключения, если их использовать с C++.

Могут. Например, вот так:

$ cat exc-leak.c

#include <string.h>
#include <stdlib.h>
#include <stdio.h>

extern "C" void f(char const* str) {
	if (str[0] != 'x')
		throw 42;
}

extern "C" int doit(void (*f)(char const*)) {
	char *str = strdup("abc");
	if (!str)
		return 1;
	f(str);
	free(str);
	return 0;
}

int main(int argc, char **argv) {
	try {
		doit(f);
		return 0;
	} catch (int x) {
		fprintf(stderr, "caught int: %d\n", x);
		return 1;
	}
	return 2;
}

$ g++ -g -Wall -x c++ exc-leak.c
$ ./a.out
caught int: 42
$ uname -m
x86_64


Вроде бы работает. За исключением того, что free() не вызывается.
А если б там был pthread_mutex_lock?

$ valgrind --leak-check=yes -v ./a.out

==9334==
==9334== HEAP SUMMARY:
==9334==     in use at exit: 4 bytes in 1 blocks
==9334==   total heap usage: 3 allocs, 2 frees, 72,840 bytes allocated
==9334==
==9334== Searching for pointers to 1 not-freed blocks
==9334== Checked 111,592 bytes
==9334==
==9334== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==9334==    at 0x4C2FB0F: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9334==    by 0x547A9B9: strdup (strdup.c:42)
==9334==    by 0x108A0F: doit (exc-leak.c:11)
==9334==    by 0x108A5D: main (exc-leak.c:21)
==9334==
==9334== LEAK SUMMARY:
==9334==    definitely lost: 4 bytes in 1 blocks
==9334==    indirectly lost: 0 bytes in 0 blocks
==9334==      possibly lost: 0 bytes in 0 blocks
==9334==    still reachable: 0 bytes in 0 blocks
==9334==         suppressed: 0 bytes in 0 blocks
==9334==
==9334== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==9334== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
asheplyakov@alexnuc:~/work/armhf$


Бросаться из C кода C++ исключениями -- почти всегда плохо.
Единственное, для чего бы я так делал -- аварийное завершение программы.

Так что те ABI/архитектуры, которые это лихачество НЕ позволяют,
делают проблему явной и облегчают жизнь программиста.

> И такую проблему может быть тяжело заметить.

1) valgrind (даже на x86) отлавливает многие такие лихачества (потому 
что они зачастую приводят к утечке памяти)
2) arm одноплатников ценой < 2000 р полно, легко собрать и запустить.
    Cойдет и rpi[234] (с 32-bit gnueabi userspace)
3) qemu-user позволяет не тратиться на одноплатники.

> Наверное, если не собирать вообще всё с -funwind-tables,
> то было бы правильно уметь отлавливать такие ситуации.
> Например, сделать какую-то добавку в rpm set provides/requires,
> чтобы приложения, собранные с этим самым EXIDX зависели от библиотек
> с EXIDX.

Убежден, что кривой код нужно чинить, а не изобретать средства,
позволяющие ему и дальше быть кривым.