On Mon, Jun 18, 2012 at 11:08:38PM +0200, Wojtek Kaniewski wrote: > Dnia 2012-06-18, pon o godzinie 21:00 +0100, Marcin Owsiany pisze: > > > Timeouty w tym teście > > > są zmniejszone do minimum, żeby nie osiwieć czekając na wyniki, co przy > > > słabym sprzęcie i/lub dużym loadzie może niestety mieć negatywny wpływ. > > > Plus to, że wywalił się test 433, a te od 324 w górę lecą po SSL-u. > > > > Gdyby dało się timeouty podbić jakąś opcją konfiguracji albo zmienną > > środowiskową, to mógłbym spróbować zwiększyć na tej architekturze albo > > przynajmniej przetestować czy pomaga. > > Możesz spróbować dodać cokolwiek, co zawiera "valgrind" do LD_PRELOAD, o > ile bzdurna wartość tej zmiennej nie szkodzi Hurdowi. Gdyby tak było, > daj znać, dodam coś innego.
W tzw międzyczasie wyleciał test na armelu: https://buildd.debian.org/status/fetch.php?pkg=libgadu&arch=armel&ver=1%3A1.12.0~pre%2Br1295-1&stamp=1340090070&file=log Z tego wynika, że ta zmiana będzie potrzebna też na architekturach linuksowych, a one już na pewno losowego napisu w LD_PRELOAD nie przełkną. Nie widzę problemu żeby testy po prostu odpalać pod valgrindem, co powinno mieć ten sam efekt uboczny w LD_PRELOAD a może przy okazji złapie jaki wyciek. Tylko powiedz mi jak to zrobić? -- Marcin Owsiany <mar...@owsiany.pl> http://marcin.owsiany.pl/ GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC "Every program in development at MIT expands until it can read mail." -- Unknown _______________________________________________ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
