[devel] middleman vs pcre

[devel] middleman vs pcre

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1171 bytes --]

2-й день сражаюсь с middleman. Дело в том, что после обновления libpcre я 
решил попробовать middleman пересобрать (мало ли), и, как ни странно, не 
получилось. (Кстати, если мой пакет, лежащий в Сизифе, перестанет 
собираться после обновления к.-л. других пакетов, я об этом узнаю?)

Дело вот в чем. С middleman идет своя libpcre (версии 3.4, судя по всему). 
И до вчерашнего дня, оказывается, собиралось именно с ней (до вчерашнего 
обновления ./configure почему-то не нравилось наше прежнее libpcre-devel). 
А новая версия ему уже нравится, и он собирает с ней. Но полученный 
бинарник падает (судя по strace) где-то при парсинге конфига (причем если 
из конфига убрать все регэкспы, то middleman нормально запускается. Но 
нафига он мне такой?). 

Видимо, придется его собирать с его собственной libpcre. Только как? Для 
hasher все понятно - убрать из Buildreqs libpcre-devel. А вообще? 
./configure при нахождении соотв. хидеров выставляет в config.h
#define HAVE_PCRE
Это можно как-то #undef-нуть без патчей, видимо, через CFLAGS=-UHAVE_PCRE ?

-- 
[...] кишки latex в сравнении с кишками passivetex это
нечто очень прямое, ровное и светлое.
		-- boyarsh in docs@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: middleman vs pcre

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Tue, Nov 11, 2003 at 05:29:13PM +0500, Andrey Rahmatullin wrote:
> Дело вот в чем. С middleman идет своя libpcre (версии 3.4, судя по всему). 
> И до вчерашнего дня, оказывается, собиралось именно с ней (до вчерашнего 
> обновления ./configure почему-то не нравилось наше прежнее libpcre-devel). 
> А новая версия ему уже нравится, и он собирает с ней. Но полученный 
> бинарник падает (судя по strace) где-то при парсинге конфига (причем если 

Под gdb можете запустить?

> из конфига убрать все регэкспы, то middleman нормально запускается. Но 
> нафига он мне такой?). 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 433 bytes --]

В сообщении от 11 Ноябрь 2003 17:36 Alexey Tourbin написал(a):

> Под gdb можете запустить?

Запустить - могу. Только навыков работы с ним у меня 0.  :-(
Точнее, запускал уже. Из ddd. Говорит "exited normally". Но судя по strace 
оно там не раз форкается. gdb это умеет?


-- 
Потребитель не всегда знает, что ему нужно :-)
На самом деле, я противник голосований, когда их результаты не обязательны 
к
исполнению.
		-- aen in devel@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] middleman vs pcre

[Stanislav Ievlev]

On Tue, Nov 11, 2003 at 05:29:13PM +0500, Andrey Rahmatullin wrote:
Content-Description: signed data
> 2-й день сражаюсь с middleman. Дело в том, что после обновления libpcre я 
> решил попробовать middleman пересобрать (мало ли), и, как ни странно, не 
> получилось. (Кстати, если мой пакет, лежащий в Сизифе, перестанет 
> собираться после обновления к.-л. других пакетов, я об этом узнаю?)
> 
> Дело вот в чем. С middleman идет своя libpcre (версии 3.4, судя по всему). 
> И до вчерашнего дня, оказывается, собиралось именно с ней (до вчерашнего 
> обновления ./configure почему-то не нравилось наше прежнее libpcre-devel). 
> А новая версия ему уже нравится, и он собирает с ней. Но полученный 
> бинарник падает (судя по strace) где-то при парсинге конфига (причем если 
> из конфига убрать все регэкспы, то middleman нормально запускается. Но 
> нафига он мне такой?). 
Как уже советовали, посмотрите через gdb. Скорее всего имеет место неверное 
использование библиотеки.
> 
> Видимо, придется его собирать с его собственной libpcre. Только как? Для 
> hasher все понятно - убрать из Buildreqs libpcre-devel. А вообще? 
Ни в коем случае так делать нельзя.
> ./configure при нахождении соотв. хидеров выставляет в config.h
> #define HAVE_PCRE
> Это можно как-то #undef-нуть без патчей, видимо, через CFLAGS=-UHAVE_PCRE ?
> 
> -- 
> [...] кишки latex в сравнении с кишками passivetex это
> нечто очень прямое, ровное и светлое.
> 		-- boyarsh in docs@



> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

[devel] Re: middleman vs pcre

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 425 bytes --]

On Tue, Nov 11, 2003 at 05:46:28PM +0500, Andrey Rahmatullin wrote:
> Запустить - могу. Только навыков работы с ним у меня 0.  :-(

Нужно статью написать про gdb. 

# apt-get install glibc-core-debug
$ rpm -bc --enable debug *.spec
$ cd ~/RPM/BUILD/*/src
$ LD_LIBRARY_PATH=/usr/lib/debug:$PWD gdb ./prog
(gdb) r
...
SIGSEGV
...
(gdb) bt

Обычно информации из последней команды бывает достаточно, чтобы
понять природу ошибки.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1812 bytes --]

В сообщении от 11 Ноябрь 2003 18:03 Alexey Tourbin написал(a):

> Нужно статью написать про gdb.

Конечно, надо.

> # apt-get install glibc-core-debug
> $ rpm -bc --enable debug *.spec
> $ cd ~/RPM/BUILD/*/src
> $ LD_LIBRARY_PATH=/usr/lib/debug:$PWD gdb ./prog
> (gdb) r
> ...
> SIGSEGV
> ...
> (gdb) bt
>
> Обычно информации из последней команды бывает достаточно, чтобы
> понять природу ошибки.

(gdb) bt
#0  0x400c2066 in chunk_alloc (ar_ptr=0x40166880, nb=40) at malloc.c:2990
#1  0x400c1ae2 in __libc_malloc (bytes=242388) at malloc.c:2811
#2  0x40106268 in byte_regex_compile (pattern=0x80e5150 
"^ad(|s|v|server)\\.", size=18, syntax=242428, bufp=0x80f1c80) at 
regex.c:2510
#3  0x40109385 in __regcomp (preg=0x80f1c80, pattern=0x80e5150 
"^ad(|s|v|server)\\.", cflags=1075210368) at regex.c:8111
#4  0x0806f537 in reg_compile (pattern=0x80e5150 "^ad(|s|v|server)\\.", 
flags=1) at src/regexp.c:33
#5  0x08054c28 in filter_ll_insert (x=0x80f1c50, profiles=0x0, comment=0x0, 
host=0x80e5150 "^ad(|s|v|server)\\.", file=0x0, template=0x0)
    at src/filter.c:396
#6  0x08054076 in filter_load (filter_list=0x80f18c0, xml_list=0x80e5108) 
at src/filter.c:126
#7  0x080566c8 in config_load (overwrite=3, file=0x80ad100 
"/etc/mman/config.xml") at src/main.c:409
#8  0x08056428 in config () at src/main.c:341
#9  0x08056e67 in mainloop () at src/main.c:612
#10 0x08055c3a in main (argc=0, argv=0xbffff9a4) at src/main.c:182
#11 0x4006d722 in __libc_start_main (main=0x805573c <main>, argc=5, 
ubp_av=0xbffff9a4, init=0x8049d14 <_init>, fini=0x40166880 <main_arena>,
    rtld_fini=0x3b2d4, stack_end=0x80f1c88) at 
../sysdeps/generic/libc-start.c:129


-- 
Ну хотя бы одно ядро в системе стоит сохранить, хотя бы на случай
перезагрузки. :)
		-- ldv in sisyphus@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On Tue, Nov 11, 2003 at 07:22:30PM +0500, Andrey Rahmatullin wrote:
> (gdb) bt
> #0  0x400c2066 in chunk_alloc (ar_ptr=0x40166880, nb=40) at malloc.c:2990
> #1  0x400c1ae2 in __libc_malloc (bytes=242388) at malloc.c:2811
> #2  0x40106268 in byte_regex_compile (pattern=0x80e5150 
> "^ad(|s|v|server)\\.", size=18, syntax=242428, bufp=0x80f1c80) at 
> regex.c:2510
> #3  0x40109385 in __regcomp (preg=0x80f1c80, pattern=0x80e5150 
> "^ad(|s|v|server)\\.", cflags=1075210368) at regex.c:8111
> #4  0x0806f537 in reg_compile (pattern=0x80e5150 "^ad(|s|v|server)\\.", 
> flags=1) at src/regexp.c:33
> #5  0x08054c28 in filter_ll_insert (x=0x80f1c50, profiles=0x0, comment=0x0, 
> host=0x80e5150 "^ad(|s|v|server)\\.", file=0x0, template=0x0)
>     at src/filter.c:396
> #6  0x08054076 in filter_load (filter_list=0x80f18c0, xml_list=0x80e5108) 
> at src/filter.c:126
> #7  0x080566c8 in config_load (overwrite=3, file=0x80ad100 
> "/etc/mman/config.xml") at src/main.c:409
> #8  0x08056428 in config () at src/main.c:341
> #9  0x08056e67 in mainloop () at src/main.c:612
> #10 0x08055c3a in main (argc=0, argv=0xbffff9a4) at src/main.c:182
> #11 0x4006d722 in __libc_start_main (main=0x805573c <main>, argc=5, 
> ubp_av=0xbffff9a4, init=0x8049d14 <_init>, fini=0x40166880 <main_arena>,
>     rtld_fini=0x3b2d4, stack_end=0x80f1c88) at 
> ../sysdeps/generic/libc-start.c:129

Вероятно, когда-то ещё до этого момента разрушены структуры malloc из-за
записи в освобождённую память либо записи за пределы выделенной области
памяти.

Попробуйте запустить программу под valgrind - он умеет отлавливать
подобные ошибки (либо используйте другой allocation debugger типа dmalloc
или ElectricFence).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Tue, Nov 11, 2003 at 04:03:31PM +0300, Alexey Tourbin wrote:
> On Tue, Nov 11, 2003 at 05:46:28PM +0500, Andrey Rahmatullin wrote:
> > Запустить - могу. Только навыков работы с ним у меня 0.  :-(
> 
> Нужно статью написать про gdb. 
> 
> # apt-get install glibc-core-debug
> $ rpm -bc --enable debug *.spec
> $ cd ~/RPM/BUILD/*/src
> $ LD_LIBRARY_PATH=/usr/lib/debug:$PWD gdb ./prog

Вот это (glibc-core-debug и LD_LIBRARY_PATH=/usr/lib/debug), кстати,
далеко не очевидная вещь (кстати, это ALT-specific, или в других
дистрибутивах тоже встречается?).  Описать это просто необходимо.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Tue, Nov 11, 2003 at 05:39:50PM +0300, Sergey Vlasov wrote:
> On Tue, Nov 11, 2003 at 04:03:31PM +0300, Alexey Tourbin wrote:
> > On Tue, Nov 11, 2003 at 05:46:28PM +0500, Andrey Rahmatullin wrote:
> > > Запустить - могу. Только навыков работы с ним у меня 0.  :-(
> > 
> > Нужно статью написать про gdb. 
> > 
> > # apt-get install glibc-core-debug
> > $ rpm -bc --enable debug *.spec
> > $ cd ~/RPM/BUILD/*/src
> > $ LD_LIBRARY_PATH=/usr/lib/debug:$PWD gdb ./prog
> 
> Вот это (glibc-core-debug и LD_LIBRARY_PATH=/usr/lib/debug), кстати,
> далеко не очевидная вещь (кстати, это ALT-specific, или в других
> дистрибутивах тоже встречается?).  Описать это просто необходимо.

А зачем вам отлаживать glibc-core? Это, кстати, далеко не очевидная вещь...


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: middleman vs pcre

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Tue, Nov 11, 2003 at 05:53:28PM +0300, Dmitry V. Levin wrote:
> > Вот это (glibc-core-debug и LD_LIBRARY_PATH=/usr/lib/debug), кстати,
> > далеко не очевидная вещь (кстати, это ALT-specific, или в других
> > дистрибутивах тоже встречается?).  Описать это просто необходимо.
> 
> А зачем вам отлаживать glibc-core? Это, кстати, далеко не очевидная вещь...

Показывает названия аргументов для libc'ишных функций при отладке
обычных программ.  Это позволяет не помнить прототипы этих функций. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

On Tue, Nov 11, 2003 at 05:53:28PM +0300, Dmitry V. Levin wrote:
> On Tue, Nov 11, 2003 at 05:39:50PM +0300, Sergey Vlasov wrote:
> > On Tue, Nov 11, 2003 at 04:03:31PM +0300, Alexey Tourbin wrote:
> > > On Tue, Nov 11, 2003 at 05:46:28PM +0500, Andrey Rahmatullin wrote:
> > > > Запустить - могу. Только навыков работы с ним у меня 0.  :-(
> > > 
> > > Нужно статью написать про gdb. 
> > > 
> > > # apt-get install glibc-core-debug
> > > $ rpm -bc --enable debug *.spec
> > > $ cd ~/RPM/BUILD/*/src
> > > $ LD_LIBRARY_PATH=/usr/lib/debug:$PWD gdb ./prog
> > 
> > Вот это (glibc-core-debug и LD_LIBRARY_PATH=/usr/lib/debug), кстати,
> > далеко не очевидная вещь (кстати, это ALT-specific, или в других
> > дистрибутивах тоже встречается?).  Описать это просто необходимо.
> 
> А зачем вам отлаживать glibc-core? Это, кстати, далеко не очевидная вещь...

Насколько я помню, без этого параметры вызовов glibc в backtrace не видны.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 918 bytes --]

В сообщении от 11 Ноябрь 2003 19:38 Sergey Vlasov написал(a):

[...]
> Попробуйте запустить программу под valgrind - он умеет отлавливать
> подобные ошибки
[...]

Ой блин...

==16664== Invalid write of size 4
==16664==    at 0x403261F9: regcomp (in /lib/libc-2.2.6.so)
==16664==    by 0x806F536: reg_compile (regexp.c:33)
==16664==    by 0x804C4E4: global_general_insert (global.c:464)
==16664==    by 0x804ACE6: global_load (global.c:102)
==16664==    Address 0x412BE104 is 4 bytes after a block of size 12 alloc'd
==16664==    at 0x40026942: malloc (vg_replace_malloc.c:153)
==16664==    by 0x806610C: xmalloc (mem.c:35)
==16664==    by 0x806F51F: reg_compile (regexp.c:31)
==16664==    by 0x804C4E4: global_general_insert (global.c:464)

И так кучу раз (похоже, что на каждый регэксп).


-- 
Вообще кто вам сказал, что Unix - это дружественно для пользователя? И 
зачем его таким нужно делать?
		-- rider in devel@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

On Tue, Nov 11, 2003 at 08:36:26PM +0500, Andrey Rahmatullin wrote:
> В сообщении от 11 Ноябрь 2003 19:38 Sergey Vlasov написал(a):
> 
> [...]
> > Попробуйте запустить программу под valgrind - он умеет отлавливать
> > подобные ошибки
> [...]
> 
> Ой блин...
> 
> ==16664== Invalid write of size 4
> ==16664==    at 0x403261F9: regcomp (in /lib/libc-2.2.6.so)
> ==16664==    by 0x806F536: reg_compile (regexp.c:33)
> ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> ==16664==    by 0x804ACE6: global_load (global.c:102)
> ==16664==    Address 0x412BE104 is 4 bytes after a block of size 12 alloc'd
> ==16664==    at 0x40026942: malloc (vg_replace_malloc.c:153)
> ==16664==    by 0x806610C: xmalloc (mem.c:35)
> ==16664==    by 0x806F51F: reg_compile (regexp.c:31)
> ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> 
> И так кучу раз (похоже, что на каждый регэксп).

И при чём тут pcre?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 255 bytes --]

В сообщении от 11 Ноябрь 2003 20:42 Dmitry V. Levin написал(a):

> И при чём тут pcre?

А я знаю?? 

-- 
С помощью chroot jail вы можете обезопасить систему от зачрутенного
сервиса гораздо надежнее, чем без использования чрутизации.
		-- ldv in sisyphus@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Tue, Nov 11, 2003 at 08:36:26PM +0500, Andrey Rahmatullin wrote:
Content-Description: signed data
> В сообщении от 11 Ноябрь 2003 19:38 Sergey Vlasov написал(a):
> 
> [...]
> > Попробуйте запустить программу под valgrind - он умеет отлавливать
> > подобные ошибки
> [...]
> 
> Ой блин...
> 
> ==16664== Invalid write of size 4
> ==16664==    at 0x403261F9: regcomp (in /lib/libc-2.2.6.so)
> ==16664==    by 0x806F536: reg_compile (regexp.c:33)
> ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> ==16664==    by 0x804ACE6: global_load (global.c:102)
> ==16664==    Address 0x412BE104 is 4 bytes after a block of size 12 alloc'd
> ==16664==    at 0x40026942: malloc (vg_replace_malloc.c:153)
> ==16664==    by 0x806610C: xmalloc (mem.c:35)
> ==16664==    by 0x806F51F: reg_compile (regexp.c:31)
> ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> 
> И так кучу раз (похоже, что на каждый регэксп).

Вот бардак... У этой дряни что, собственное левое определение regex_t
(такая гадость иногда встречается)?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] К вопросу о pcre

[Igor Tertishny]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 418 bytes --]

У меня тоже проблемы с pcre - kile, например:

 leiconview.o kilefileselect.o kileapplication.o kileappIface_skel.o 
gotolinedialog.o finddialog.o filechooser.o docpart.o arraydialog.o kile.o 
main.o ./gfe/libgfe.a -lkdeprint -lkspell -lkhtml 
libtool: link: cannot find the library `/usr/lib/libpcre.la'

И как этот вопрос решать? Попробую завтра убрать  libpcre-devel из 
Buildrequires, но это, помню, не помогало.


[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] К вопросу о pcre

[Yuri N. Sedunov]

On 12 Ноябрь 2003 00:29, Igor Tertishny wrote:
> У меня тоже проблемы с pcre - kile, например:
>
>  leiconview.o kilefileselect.o kileapplication.o kileappIface_skel.o
> gotolinedialog.o finddialog.o filechooser.o docpart.o arraydialog.o kile.o
> main.o ./gfe/libgfe.a -lkdeprint -lkspell -lkhtml
> libtool: link: cannot find the library `/usr/lib/libpcre.la'
>
> И как этот вопрос решать? Попробую завтра убрать  libpcre-devel из
> Buildrequires, но это, помню, не помогало.

Вам можно ничего не делать и просто подождать новой сборки kdelibs.

-- 
Yuri N. Sedunov

Re: [devel] middleman-1.9-alt4: rebuild failed (was: middleman vs pcre)

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 282 bytes --]

В сообщении от 11 Ноябрь 2003 17:29 Andrey Rahmatullin написал(a):

Ну вот... Что делать-то? Может его как-то все-таки со встроенной собирать?

-- 
Пишите в sisyphus@, в этом списке рассылки я вам на этот в целом
неплохой вопрос не отвечу - policy запрещает.
		-- ldv in community@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Stanislav Ievlev]

On Tue, Nov 11, 2003 at 06:47:50PM +0300, Sergey Vlasov wrote:
> On Tue, Nov 11, 2003 at 08:36:26PM +0500, Andrey Rahmatullin wrote:
> Content-Description: signed data
> > В сообщении от 11 Ноябрь 2003 19:38 Sergey Vlasov написал(a):
> > 
> > [...]
> > > Попробуйте запустить программу под valgrind - он умеет отлавливать
> > > подобные ошибки
> > [...]
> > 
> > Ой блин...
> > 
> > ==16664== Invalid write of size 4
> > ==16664==    at 0x403261F9: regcomp (in /lib/libc-2.2.6.so)
> > ==16664==    by 0x806F536: reg_compile (regexp.c:33)
> > ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> > ==16664==    by 0x804ACE6: global_load (global.c:102)
> > ==16664==    Address 0x412BE104 is 4 bytes after a block of size 12 alloc'd
> > ==16664==    at 0x40026942: malloc (vg_replace_malloc.c:153)
> > ==16664==    by 0x806610C: xmalloc (mem.c:35)
> > ==16664==    by 0x806F51F: reg_compile (regexp.c:31)
> > ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> > 
> > И так кучу раз (похоже, что на каждый регэксп).
> 
> Вот бардак... У этой дряни что, собственное левое определение regex_t
> (такая гадость иногда встречается)?
Если это намёк на pcre, то почему сразу дрянь. Имеет право.
Всё что связано с regex это weekalias (как просвятил меня Дима). У pcre же есть очень удобный POSIX интерфейс с поддержкой расширений perl. А уж если POSIX интерфейс, то и есть regex_t. Было бы удивительно если бы она (pcre) использовала glibc'шный.

Вот если бы glic'шный regex поддерживал бы отмену жадности (?) то многие бы не стали пользоваться pcre. Например я.

> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

[devel] Re: middleman-1.9-alt4: rebuild failed (was: middleman vs pcre)

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 198 bytes --]

On Wed, Nov 12, 2003 at 08:17:37AM +0500, Andrey Rahmatullin wrote:
> Ну вот... Что делать-то? Может его как-то все-таки со встроенной собирать?

Со встроенной собирать нельзя.
QA Team вам поможет.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] middleman-1.9-alt4: rebuild failed (was: middleman vs pcre)

[Stanislav Ievlev]

On Wed, Nov 12, 2003 at 08:17:37AM +0500, Andrey Rahmatullin wrote:
Content-Description: signed data
> В сообщении от 11 Ноябрь 2003 17:29 Andrey Rahmatullin написал(a):
> 
> Ну вот... Что делать-то? Может его как-то все-таки со встроенной собирать?
Ни за что. Этого ни в коем случае нельзя делать. Вспомните проблему zlib.
Ищите багу.
> 
> -- 
> Пишите в sisyphus@, в этом списке рассылки я вам на этот в целом
> неплохой вопрос не отвечу - policy запрещает.
> 		-- ldv in community@



> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

Re: [devel] Re: middleman vs pcre

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2068 bytes --]

On Wed, Nov 12, 2003 at 11:32:49AM +0300, Stanislav Ievlev wrote:
> On Tue, Nov 11, 2003 at 06:47:50PM +0300, Sergey Vlasov wrote:
> > On Tue, Nov 11, 2003 at 08:36:26PM +0500, Andrey Rahmatullin wrote:
> > Content-Description: signed data
> > > В сообщении от 11 Ноябрь 2003 19:38 Sergey Vlasov написал(a):
> > > 
> > > [...]
> > > > Попробуйте запустить программу под valgrind - он умеет отлавливать
> > > > подобные ошибки
> > > [...]
> > > 
> > > Ой блин...
> > > 
> > > ==16664== Invalid write of size 4
> > > ==16664==    at 0x403261F9: regcomp (in /lib/libc-2.2.6.so)
> > > ==16664==    by 0x806F536: reg_compile (regexp.c:33)
> > > ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> > > ==16664==    by 0x804ACE6: global_load (global.c:102)
> > > ==16664==    Address 0x412BE104 is 4 bytes after a block of size 12 alloc'd
> > > ==16664==    at 0x40026942: malloc (vg_replace_malloc.c:153)
> > > ==16664==    by 0x806610C: xmalloc (mem.c:35)
> > > ==16664==    by 0x806F51F: reg_compile (regexp.c:31)
> > > ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> > > 
> > > И так кучу раз (похоже, что на каждый регэксп).
> > 
> > Вот бардак... У этой дряни что, собственное левое определение regex_t
> > (такая гадость иногда встречается)?
> Если это намёк на pcre, то почему сразу дрянь. Имеет право.
> Всё что связано с regex это weekalias (как просвятил меня Дима). У
> pcre же есть очень удобный POSIX интерфейс с поддержкой расширений
> perl. А уж если POSIX интерфейс, то и есть regex_t. Было бы
> удивительно если бы она (pcre) использовала glibc'шный.

Ну здесь-то явно используется regcomp из glibc.  Т.е. где-то
перепутались заголовки и библиотеки.

Против самой pcre я не выступаю.  А вот pcreposix - это гадость, т.к.
вполне может сломать работу POSIX regexp в других библиотеках (не
glibc).  Следовало бы делать эту эмуляцию не прямым переопределением
regcomp/regexec/..., а через #define regcomp __pcre_regcomp в
<pcreposix.h> - тогда это бы влияло только на файлы, которые были
скомпилированы с #include <pcreposix.h>.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Stanislav Ievlev]

On Wed, Nov 12, 2003 at 12:24:20PM +0300, Sergey Vlasov wrote:
> On Wed, Nov 12, 2003 at 11:32:49AM +0300, Stanislav Ievlev wrote:
> > On Tue, Nov 11, 2003 at 06:47:50PM +0300, Sergey Vlasov wrote:
> > > On Tue, Nov 11, 2003 at 08:36:26PM +0500, Andrey Rahmatullin wrote:
> > > Content-Description: signed data
> > > > В сообщении от 11 Ноябрь 2003 19:38 Sergey Vlasov написал(a):
> > > > 
> > > > [...]
> > > > > Попробуйте запустить программу под valgrind - он умеет отлавливать
> > > > > подобные ошибки
> > > > [...]
> > > > 
> > > > Ой блин...
> > > > 
> > > > ==16664== Invalid write of size 4
> > > > ==16664==    at 0x403261F9: regcomp (in /lib/libc-2.2.6.so)
> > > > ==16664==    by 0x806F536: reg_compile (regexp.c:33)
> > > > ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> > > > ==16664==    by 0x804ACE6: global_load (global.c:102)
> > > > ==16664==    Address 0x412BE104 is 4 bytes after a block of size 12 alloc'd
> > > > ==16664==    at 0x40026942: malloc (vg_replace_malloc.c:153)
> > > > ==16664==    by 0x806610C: xmalloc (mem.c:35)
> > > > ==16664==    by 0x806F51F: reg_compile (regexp.c:31)
> > > > ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> > > > 
> > > > И так кучу раз (похоже, что на каждый регэксп).
> > > 
> > > Вот бардак... У этой дряни что, собственное левое определение regex_t
> > > (такая гадость иногда встречается)?
> > Если это намёк на pcre, то почему сразу дрянь. Имеет право.
> > Всё что связано с regex это weekalias (как просвятил меня Дима). У
> > pcre же есть очень удобный POSIX интерфейс с поддержкой расширений
> > perl. А уж если POSIX интерфейс, то и есть regex_t. Было бы
> > удивительно если бы она (pcre) использовала glibc'шный.
> 
> Ну здесь-то явно используется regcomp из glibc.  Т.е. где-то
> перепутались заголовки и библиотеки.
Наверное забыли -lpcreposix?
> 
> Против самой pcre я не выступаю.  А вот pcreposix - это гадость, т.к.
> вполне может сломать работу POSIX regexp в других библиотеках (не
> glibc).  
Не поломает, если будут использовать что-то одно ;)
>Следовало бы делать эту эмуляцию не прямым переопределением
> regcomp/regexec/..., а через #define regcomp __pcre_regcomp в
> <pcreposix.h> - тогда это бы влияло только на файлы, которые были
> скомпилированы с #include <pcreposix.h>.
Самое смешное, что теперь так и есть ;)


> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

Re: [devel] Re: middleman vs pcre

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]

On Wed, Nov 12, 2003 at 12:45:49PM +0300, Stanislav Ievlev wrote:
> On Wed, Nov 12, 2003 at 12:24:20PM +0300, Sergey Vlasov wrote:
> > On Wed, Nov 12, 2003 at 11:32:49AM +0300, Stanislav Ievlev wrote:
> > > On Tue, Nov 11, 2003 at 06:47:50PM +0300, Sergey Vlasov wrote:
> > > > On Tue, Nov 11, 2003 at 08:36:26PM +0500, Andrey Rahmatullin wrote:
> > > > Content-Description: signed data
> > > > > В сообщении от 11 Ноябрь 2003 19:38 Sergey Vlasov написал(a):
> > > > > 
> > > > > [...]
> > > > > > Попробуйте запустить программу под valgrind - он умеет отлавливать
> > > > > > подобные ошибки
> > > > > [...]
> > > > > 
> > > > > Ой блин...
> > > > > 
> > > > > ==16664== Invalid write of size 4
> > > > > ==16664==    at 0x403261F9: regcomp (in /lib/libc-2.2.6.so)
> > > > > ==16664==    by 0x806F536: reg_compile (regexp.c:33)
> > > > > ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> > > > > ==16664==    by 0x804ACE6: global_load (global.c:102)
> > > > > ==16664==    Address 0x412BE104 is 4 bytes after a block of size 12 alloc'd
> > > > > ==16664==    at 0x40026942: malloc (vg_replace_malloc.c:153)
> > > > > ==16664==    by 0x806610C: xmalloc (mem.c:35)
> > > > > ==16664==    by 0x806F51F: reg_compile (regexp.c:31)
> > > > > ==16664==    by 0x804C4E4: global_general_insert (global.c:464)
> > > > > 
> > > > > И так кучу раз (похоже, что на каждый регэксп).
> > > > 
> > > > Вот бардак... У этой дряни что, собственное левое определение regex_t
> > > > (такая гадость иногда встречается)?
> > > Если это намёк на pcre, то почему сразу дрянь. Имеет право.
> > > Всё что связано с regex это weekalias (как просвятил меня Дима). У
> > > pcre же есть очень удобный POSIX интерфейс с поддержкой расширений
> > > perl. А уж если POSIX интерфейс, то и есть regex_t. Было бы
> > > удивительно если бы она (pcre) использовала glibc'шный.
> > 
> > Ну здесь-то явно используется regcomp из glibc.  Т.е. где-то
> > перепутались заголовки и библиотеки.
> Наверное забыли -lpcreposix?

Похоже на то.

> > Против самой pcre я не выступаю.  А вот pcreposix - это гадость, т.к.
> > вполне может сломать работу POSIX regexp в других библиотеках (не
> > glibc).  
> Не поломает, если будут использовать что-то одно ;)

Поломает - если другая libxxx.so была скомпилирована с regex из glibc,
а получит реализацию из libpcreposix.so.

> >Следовало бы делать эту эмуляцию не прямым переопределением
> > regcomp/regexec/..., а через #define regcomp __pcre_regcomp в
> > <pcreposix.h> - тогда это бы влияло только на файлы, которые были
> > скомпилированы с #include <pcreposix.h>.
> Самое смешное, что теперь так и есть ;)

Ну вот и прекрасно - видимо, на это уже кто-то наступил.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] К вопросу о pcre

[Igor Tertishny]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 112 bytes --]

>
> Вам можно ничего не делать и просто подождать новой сборки kdelibs.

Увы мне, но другого выхода не вижу... 

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 540 bytes --]

В сообщении от 12 Ноябрь 2003 14:45 Stanislav Ievlev написал(a):
[...]
> > Ну здесь-то явно используется regcomp из glibc.  Т.е. где-то
> > перепутались заголовки и библиотеки.
>
> Наверное забыли -lpcreposix?

wrar@wrars-comp RPM/BUILD/middleman $ cat Makefile |grep lpcrep
LIBS = -ldl  -pthread -lpcre -lpcreposix -lz

вроде на месте ;-)

[...]

-- 
Я получил от nidd сообщение, что у него есть запись перекрёстного
допроса aka F.A.Q. на эту тему. Запись будет приложена к материалам
следствия по делу подсудимого XKB.
		-- avp in devel@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] middleman-1.9-alt4: rebuild failed (was: middleman vs pcre)

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 389 bytes --]

В сообщении от 12 Ноябрь 2003 13:34 Stanislav Ievlev написал(a):

[...]
> Вспомните проблему zlib.

Не застал ;-) Расскажите, плиз.

[...]

-- 
На основании этого можно сделать очевидные выводы:
+ нам удобно, чтобы чужие spec-файлы у нас работали (хотя бы для удобства
  подготовки своего spec-файла);
+ нам все равно, будут ли наши spec-файлы работать где-либо еще.
		-- ldv in sisyphus@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: middleman vs pcre

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1435 bytes --]

В сообщении от 12 Ноябрь 2003 14:24 Sergey Vlasov написал(a):

[...]
> Ну здесь-то явно используется regcomp из glibc.  Т.е. где-то
> перепутались заголовки и библиотеки.

Удалось выяснить, что всё именно так. Но я ничего не понимаю. 

wrar@wrars-comp RPM/BUILD/middleman $ grep PCRE config.h
#define HAVE_PCRE 1

Здесь правильно. Далее:

wrar@wrars-comp RPM/BUILD/middleman $ head -n13 include/proto.h | tail -n9
#include "../config.h"

#ifdef HAVE_PCRE
#include <pcre/pcre.h>
#include <pcre/pcreposix.h>
#else
#include "../pcre/pcre.h"
#include "../pcre/pcreposix.h"
#endif /* HAVE_PCRE */


Получается, препроцессор должен развернуть это в 
#include <pcre/pcre.h>
#include <pcre/pcreposix.h>
Так?


А вот нифига. Всё чуть посложнее ;-) Дело в том, что config.h инклюдится еще и 
через -I. в Makefile. И получается вот что:

$ cpp -Iinclude -I. src/regexp.c > regexp_with_config_h.i
- так при компиляции

$ cpp -Iinclude src/regexp.c > regexp_without_config_h.i
- так хотелось бы

$ diff regexp_with_config_h.i regexp_without_config_h.i | head -n6
180,181c180,181
< # 1 "pcre/pcre.h" 1
< # 32 "pcre/pcre.h"
---
> # 1 "/usr/include/pcre/pcre.h" 1 3
> # 37 "/usr/include/pcre/pcre.h" 3

Я, конечно, С знаю совсем недостаточно, но... Если одна и та же #define 
встречается 2 раза, она #undef-ается? 


Т.о., убивать одно из упоминаний config.h и всё будет ОК?
[...]

-- 
Не надо советовать создавать в / что-либо.
		-- ldv in sisyphus@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: middleman vs pcre

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On Wed, Nov 12, 2003 at 07:22:18PM +0500, Andrey Rahmatullin wrote:
> $ cpp -Iinclude -I. src/regexp.c > regexp_with_config_h.i
> - так при компиляции

Я тоже успел разобраться с этой проблемой.
Решается она так:


--- /home/at/RPM/SPECS/middleman.spec-	2003-10-21 14:52:03 +0400
+++ /home/at/RPM/SPECS/middleman.spec	2003-11-12 17:34:59 +0300
@@ -32,9 +32,11 @@
 
 %prep
 %setup -n %name
+%__rm -rfv pcre
 %patch1 -p1
 
 %build
+%add_optflags -I%_includedir/pcre
 %configure \
     --enable-syslog \
     --disable-pam

Совет: в подобных случаях стоит удалять ВСЁ, что вы не собираетесь
использовать, на стадии %prep.  Теперь по-видимому всё работает.

$ sudo service mman start
Starting mman service: [ DONE ]
$ sudo service mman status
mman is running
$

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] U: middleman-1.9.1-alt1 (was: middleman vs pcre)

[Andrey Rahmatullin]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 85 bytes --]

Заливаю 8-)

-- 
Нет, не забросил. Я его специально не собираю.
		-- rider in devel@

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] middleman-1.9-alt4: rebuild failed (was: middleman vs pcre)

[Stanislav Ievlev]

On Wed, Nov 12, 2003 at 06:12:35PM +0500, Andrey Rahmatullin wrote:
Content-Description: signed data
> В сообщении от 12 Ноябрь 2003 13:34 Stanislav Ievlev написал(a):
> 
> [...]
> > Вспомните проблему zlib.
> 
> Не застал ;-) Расскажите, плиз.
Всё очень просто. Из-за того что куча программ таскала с собой свою копию
zlib и собиралась с ней статически, то когда надо было сделать security
update, вместо того чтобы пересобрать одну библиотеку пришлось
пересобирать ой как много програм. С тех пор, если не ошибаюсь, даже в ядре zlib оторван.
> 
> [...]
> 
> -- 
> На основании этого можно сделать очевидные выводы:
> + нам удобно, чтобы чужие spec-файлы у нас работали (хотя бы для удобства
>   подготовки своего spec-файла);
> + нам все равно, будут ли наши spec-файлы работать где-либо еще.
> 		-- ldv in sisyphus@



> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel