[gnome-cyr] =?koi8-r?q?Re=3A_=5Bgnome-cyr=5D_Re=3A_=5Bgnome-cyr=5D_Re=3A_?==?koi8-r?q?=5Bgnome-cyr=5D_Re=3A_=5Bgnome-cyr=5D_Re=3A_=5Bgnome-c?==?koi8-r?q?yr=5D_Re=3A__=5Bgnome-cyr=5D_Evolution-0=2E11=C9__?==?koi8-r?q?=C4=C1=D4=D9?=

[Vlad Harchev <hvv hippo ru>]

On Wed, 1 Aug 2001, Vlad Harchev wrote:

 Привет всем!

> On Thu, 26 Jul 2001, Vlad Harchev wrote:
> 
>  Hi, 
> 
>  Короче, я запостил багрепорт на glibc  в RH bugzilla:
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=50564
> 
>  С самим gnumeric разберусь попозже.

 Короче, оказалось что ошибка была и в regcomp(3) тоже (именно из-за ошибки в
regcomp функция wctomb получала отрицательный 2ой аргумент). Это прекрасно
видно из того же backtrace'а.
 gnumeric АБСОЛЮТО не причем. Зря я их поливал грязью..

 Отослал 2а багрепорта (про wctomb и regcomp) на bug-glibc gnu org (никаких
изменений в статусе отквоченной баги в Redhat bugzilla пока не случилось)..

 Best regards,
  -Vlad

> ---------------------------
>               Product - Version Component Status Short Summary
>    Red Hat Linux - 7.1 glibc NEW function wctomb shouldn't crash if wchar
>                           passed to it is negative
> 
>      Opened by hvv hippo ru on  2001-08-01 05:38:23   Long Description
> 
> 
> Description of Problem: In a lot of lame code, char (that is signed) is passed
> directly as argument to wctomb - so it gets negative argument. Glibc shipped
> with RH7.1 crashes when this happens.
> 
> 
> How Reproducible: Try to start gnumeric 0.67 under russian locale or write a
> small testsuite yourself.
> 
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> 
> 
>  Best regards,
>   -Vlad
> 
> 
> > On Thu, 26 Jul 2001, Sergey V. Udaltsov wrote:
> > 
> > > 
> > > > > Про пакеты не знаю. Просто не собирался гнумерик на красной шапке и всё.
> > > Очень странно. На днях я спокойно собрал gnumeric 0.67 из эсэрпээма.
> > > Но с русской локалью он действительно падает на взлете (с C и en_US все
> > > в порядке).
> > > gdb выдает такое:
> > > 
> > > (no debugging symbols found)...0x40864519 in __wait4 ()
> > >    from /lib/i686/libc.so.6
> > > #0  0x40864519 in __wait4 () from /lib/i686/libc.so.6
> > > #1  0x408d49e4 in __DTOR_END__ () from /lib/i686/libc.so.6
> > > #2  0x404a3262 in gnome_segv_handle (signum=11) at gnome-init.c:659
> > > #3  <signal handler called>
> > > #4  0x40956f73 in gconv () from /usr/lib/gconv/KOI8-R.so
> > > #5  0x4083688a in __wcrtomb (s=0xbffff590 "\210\002", wc=-15,
> > > ps=0x408d8aa0)
> > >     at wcrtomb.c:85
> > > #6  0x407da8cf in wctomb (s=0xbffff590 "\210\002", wchar=-15) at
> > > wctomb.c:53
> > > #7  0x40875bd8 in __re_compile_fastmap (bufp=0xbffff630) at regex.c:4567
> > > #8  0x40879c24 in __regcomp (preg=0xbffff630, 
> > >     pattern=0x8201720
> > > "^(Янв|Фев|Мар|Апр|Май|Июн|Июл|Авг|Сен|Окт|Ноя|Дек)-([0-9][0-9]?)-([0-9][0-9]?)$",
> > > cflags=3) at regex.c:7745
> > > #9  0x080aebe5 in format_match_define () at eval.c:41
> > > #10 0x080aee22 in format_match_init () at eval.c:41
> > > #11 0x080a41d6 in item_grid_get_type () at eval.c:41
> > > #12 0x080a4445 in main () at eval.c:41
> > > #13 0x407c6177 in __libc_start_main (main=0x80a4430 <main>, argc=1, 
> > >     ubp_av=0xbffff7c4, init=0x806b168 <_init>, fini=0x814d2c0 <_fini>, 
> > >     rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffff7bc)
> > >     at ../sysdeps/generic/libc-start.c:129
> > > #0  0x40864519 in __wait4 () from /lib/i686/libc.so.6
> > > No locals.
> > > #1  0x408d49e4 in __DTOR_END__ () from /lib/i686/libc.so.6
> > > No symbol table info available.
> > > #2  0x404a3262 in gnome_segv_handle (signum=11) at gnome-init.c:659
> > > 	in gnome-init.c
> > > estatus = -1073745168
> > > in_segv = 1
> > > pid = 0
> > > #3  <signal handler called>
> > > No locals.
> > > #4  0x40956f73 in gconv () from /usr/lib/gconv/KOI8-R.so
> > > No symbol table info available.
> > > #5  0x4083688a in __wcrtomb (s=0xbffff590 "\210\002", wc=-15,
> > > ps=0x408d8aa0)
> > >     at wcrtomb.c:85
> > > 	in wcrtomb.c
> > > s = 0xbffff590 "\210\002"
> > > Идеи?
> > 
> >  Так я и думал - проблемы в коде, специфичном для локали:
> > > #5  0x4083688a in __wcrtomb (s=0xbffff590 "\210\002", wc=-15,
> > 							^^^^^^
> > > ps=0x408d8aa0)
> >  
> > 
> >  Проблема в гнумерик, со знаками:
> >  	int((char)'Я') == -15
> >  Вот откуда берется (-15) на которой падает __wcrtomb.
> >  Почему-то каждый символ строки 
> > 
> > "^(Янв|Фев|Мар|Апр|Май|Июн|Июл|Авг|Сен|Окт|Ноя|Дек)-([0-9][0-9]?)-([0-9][0-9]$"
> > 
> >  Почему-то разработчики gnumeric считают, что названия месяцев могут быть
> > только в ascii (функция будет падать если название содержит даже символ из
> > верхней половины iso8859-1 - так как char по ISO C spec signed!). 
> >  
> >  Короче, временное решение - убрать перевод
> > "^(Янв|Фев|Мар|Апр|Май|Июн|Июл|Авг|Сен|Окт|Ноя|Дек)-([0-9][0-9]?)-([0-9][0-9]$"
> >  (если он есть в .po) или пофиксить функцию которая генерит эту строку.
> > 
> >  По-хорошему надо сказать разработчикам что они облажались в 
> > format_match_define() и что хотя бы надо делать casting. 
> > 
> > > >  Так это совершенно разные вещи - собираемость и глючность работы
> > > > скомпиленного, и они ни как не связаны.
> > > Собирать evolution не пытался - не выкладывают, собаки, эсэрпээмов
> > > вовремя... А бинарник действительно валится, как подкошенный...
> > 
> >  Под любой локалью?
> >  Опять - попробуйте убить каталог русских сообщений и пустить evo.