[debug] libwebkit и png (отладочные символы)

0

0

Собрал libwebkit, поставил uzbl и midori. Оба падают по SIGSEGV. Посмотрел backtrace в gdb: указал он мне, что беда в libwebkit, в его png-части. Это подтвердилось тестированием «вживую»: падает при попытке открыть png, а, например, с jpeg всё ok. Чтобы понять в чем конкретно дело нужны были отладочные символы, попытался собрать libwebkit с --enable-debug. Это заняло на порядок больше времени, но еще «выпало» с ошибками(без отладочных символов всё собиралось нормально). Но, что хуже, либа получилась размером в 400+MiB и в gdb её стало малореально отлаживать(у меня 512MiB памяти :)). В связи с этим вопрос: можно ли построить отдельно целевой la-файл с отладочными символами, а всё остальное - без? Ну, или посоветуйте какой-нибудь метод отладки без них. )

Ссылка

←	[gcc][libconfig] указатель на указатель

code::blocks линкует, но не запускается

→

а бэктрейс по корке что показывает? может, проще libpng с дебагом собрать?

ananas ★★★★★
(11.04.10 16:59:24 MSD)

Ответ на: комментарий от ananas 11.04.10 16:59:24 MSD

может проще использовать нормальный дистрибутив в котором есть -debug репозиторий?

Reset ★★★★★
(11.04.10 17:47:54 MSD)

Ответ на: комментарий от ananas 11.04.10 16:59:24 MSD

Спасибо за ответ. Вот что дает bt в gdb:

Program received signal SIGSEGV, Segmentation fault.
0xb63e93f6 in _setjmp () from /lib/libc.so.6
(gdb) bt
#0  0xb63e93f6 in _setjmp () from /lib/libc.so.6
#1  0xb70c97ac in WebCore::PNGImageReader::decode(WebCore::SharedBuffer const&, bool) () from /usr/lib/libwebkit-1.0.so.2
#2  0xb70c948c in WebCore::PNGImageDecoder::decode(bool) () from /usr/lib/libwebkit-1.0.so.2
#3  0xb70c9656 in WebCore::PNGImageDecoder::isSizeAvailable() () from /usr/lib/libwebkit-1.0.so.2
#4  0xb6e05b09 in WebCore::ImageSource::isSizeAvailable() () from /usr/lib/libwebkit-1.0.so.2
#5  0xb6df0620 in WebCore::BitmapImage::isSizeAvailable() () from /usr/lib/libwebkit-1.0.so.2
#6  0xb6e0569a in WebCore::Image::setData(WTF::PassRefPtr<WebCore::SharedBuffer>, bool) () from /usr/lib/libwebkit-1.0.so.2
#7  0xb6d133d7 in WebCore::CachedImage::data(WTF::PassRefPtr<WebCore::SharedBuffer>, bool) () from /usr/lib/libwebkit-1.0.so.2
#8  0xb6d6e82b in WebCore::Loader::Host::didReceiveData(WebCore::SubresourceLoader*, char const*, int) () from /usr/lib/libwebkit-1.0.so.2
#9  0xb6d6094a in WebCore::SubresourceLoader::didReceiveData(char const*, int, long long, bool) () from /usr/lib/libwebkit-1.0.so.2
#10 0xb6d5af08 in WebCore::ResourceLoader::didReceiveData(WebCore::ResourceHandle*, char const*, int, int) () from /usr/lib/libwebkit-1.0.so.2
#11 0xb70ca608 in WebCore::gotChunkCallback(_SoupMessage*, SoupBuffer*, void*) () from /usr/lib/libwebkit-1.0.so.2
#12 0xb7eb5548 in IA__g_cclosure_marshal_VOID__BOXED (closure=0x838acd8, return_value=0x0, n_param_values=2, param_values=0x58a, invocation_hint=0xbfffd250,
    marshal_data=0x8398590) at gmarshal.c:566
<и далее до main() через пару других либ>

В исходнике png-«части» WebCore есть 3 вызова longjmp(): 2 в функции на которую я ставил breakpoint(gdb на ней не останавливался) и 1 в - насколько я понял - callback-функции передаваемой в libpng для обработки ошибок декодирования пользователем(т.е. libwebkit) этой самой libpng. Собрал libpng c "-ggdb3"; обе либы вроде бы с отладочными символами:

$ ldd `which midori` | grep webkit
        libwebkit-1.0.so.2 => /usr/lib/libwebkit-1.0.so.2 (0xb6023000)
$ ldd /usr/lib/libwebkit-1.0.so.2 | grep png
        libpng14.so.14 => /usr/lib/libpng14.so.14 (0xb5f10000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb4794000)
$ ls -l /usr/lib/libpng12.so.0
lrwxrwxrwx 1 root root 18 Apr 11 19:08 /usr/lib/libpng12.so.0 -> libpng12.so.0.43.0
$ file /usr/lib/libpng12.so.0.43.0 
/usr/lib/libpng12.so.0.43.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
$ file /usr/lib/libpng14.so.14
libpng14.so.14      libpng14.so.14.1.0  
$ file /usr/lib/libpng14.so.14.1.0 
/usr/lib/libpng14.so.14.1.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
$ ldd `which dillo` | grep png
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7708000)
        libpng14.so.14 => /usr/lib/libpng14.so.14 (0xb76e5000)
$ ldd `which wxyzv` | grep png
        libpng14.so.14 => /usr/lib/libpng14.so.14 (0xb74f4000)

К сожалению, ничего нового по bt gdb не показал. Кстати с Dillo и wxyzv при открытии png-файлов проблем нет.

xkitenz ★
(11.04.10 20:22:17 MSD)

Ответ на: комментарий от Reset 11.04.10 17:47:54 MSD

может проще использовать нормальный дистрибутив в котором есть -debug репозиторий?

Ну, отказываться от свободы выбора и менять диструбутив, когда уже почти вся система собрана как-то странно. ) И на моей второй системе(ubuntu-клон) сегфолтов не наблюдается, так что хочется-таки разобратся в чем же собственно дело, да и полезных навыков в процессе приобрести.

xkitenz ★
(11.04.10 20:28:32 MSD)