enlightenment-0.16.5

[Tomasz Kłoczko]

.. wiadomo że nie działa i wali się z sigseg przy inicjacji.
Wyciąg z back trace:

#0  0x003f09c8 in vfprintf () from /lib/libc.so.6
#1  0x0040cb2a in vsnprintf () from /lib/libc.so.6
#2  0x003f7fc8 in snprintf () from /lib/libc.so.6
#3  0x08080068 in OpenConfigFileForReading ( path=0x813ca50
    "/usr/X11R6/share/enlightenment/themes/BrushedMetal-Tigert/init.cfg",
    preprocess=1 '\001') at config.c:3269
                            ^^^^^^^^^^^^^
#4  0x080803e5 in LoadConfigFile (f=0x810c6ae "init.cfg") at config.c:3379
#5  0x080811e1 in LoadEConfig (
    themelocation=0x812ad00 "/usr/X11R6/share/enlightenment/themes/BrushedMetal-Tigert")
    at config.c:3786
#6  0x080c982b in main (argc=1, argv=0xbffffc94) at main.c:259
#7  0x003bc7d1 in __libc_start_main () from /lib/libc.so.6

Nie mogę jakoś dać sobie rady z namierzeniem przez co to się wali w
config.c. Mógłby ktoś pomóc ? W tej linni jest snprintf() (w orginale
Esnprintf()) na kilka linijek i jakoś nie mogę sie połapać w którym
miejscu rozwijanie łańcucha jest walnięte :>

W międzyczasie niejako przy okazji zmontowałem jeszcze poprawkę na
używanie snprintf() z glibc zamiast własnego (w pierwzym odruchu myślałem,
że coś jest nie tak z tym Esnprintf() jakie jest w E). Swoja droga ciekawe
ile jest takich programów jeszcze które różne funkcje które są w glibc
dublują w własnym kodzie (snprintf(), glob(), getopt() czy inne).

Przy oazji. Używający nss_db proszeni są o wykonanie upgrade i sprawdzenie
czy baza z mapą shadow ma właściwe uprawnienia (o-r).

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*