Dnia 2014-06-01, nie o godzinie 20:46 +0200, Wojtek Kaniewski pisze:
> Mógłbyś spróbować zamiast tego dodać na początku funkcji
> gg_resolver_pthread_thread() coś takiego?
>
> pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
>
> Teraz już wróżę z fusów, ale różnice w dokumentacji pth
Dnia 2014-06-01, nie o godzinie 23:01 +0200, Wojtek Kaniewski pisze:
> Dodanie volatile pomaga (gcc 4.8.2). Jak patrzę na wygenerowany kod
> asemblerowy, to nie mam najmniejszego pojęcia, co się tam dzieje.
> Myślałem, że jak spojrzę na implementację pthread_cleanup_push() i
> _pop() to czegoś się
Dnia 2014-06-01, nie o godzinie 21:08 +0200, Jakub Zawadzki pisze:
> Próbowałeś może uruchomić swój test pod valgrindem?
Puszczałem z memcheckiem i helgrindem, żeby wykryć jakiś głupi dostęp do
pamięci, ale nie patrzyłem na wycieki pamięci. Faktycznie coś jest.
> Wygląda że moje gcc-4.6 optymali
Cześć,
On Sun, Jun 01, 2014 at 03:06:13PM +0200, Wojtek Kaniewski wrote:
> Co do samego błędu, na który trafił Dominik, to zmieniłem test resolvera
> tak, żeby w kółko tworzył wątek i po losowym czasie (rzędu milisekund)
> go ubijał. (...)
>
> Niestety po przekompilowaniu libgadu nową wersję gcc
Dnia 2014-05-27, wto o godzinie 18:50 +0200, Dominik 'Rathann'
Mierzejewski pisze:
> Niestety, nie pomaga. Nadal mam segfaulty. Natomiast tak, jak pisałem, dodanie
>
> pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
>
> w linii 535 src/resolver.c pomaga.
Mógłbyś spróbować zamiast tego dod
Dnia 2014-05-27, wto o godzinie 23:01 +0200, Tomasz Wasilczyk pisze:
>
> Wolałbym nie stosować takiej "armaty" na tego buga, a raczej
> zdiagnozować go dokładniej. Jeżeli byśmy tak zrobili, to nie będzie
> się dało anulować rozpoznawania nazw (nie jest to jednak tragedia).
>
>
> Chodzi o to, że
W dniu 27 maja 2014 18:50 użytkownik Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> napisał:
> On Monday, 26 May 2014 at 20:42, Tomasz Wasilczyk wrote:
> > Mamy CI właśnie na Fedorze 19 32bit i nie mamy problemów z testami
> > automatycznymi, więc nie mam możliwości przetestować tego oso
On Monday, 26 May 2014 at 20:42, Tomasz Wasilczyk wrote:
> Mamy CI właśnie na Fedorze 19 32bit i nie mamy problemów z testami
> automatycznymi, więc nie mam możliwości przetestować tego osobiście.
Cóż, mi segfaultuje zarówno na builderach Fedory (za każdym razem),
jak i lokalnie (mniej więcej co 3
Mamy CI właśnie na Fedorze 19 32bit i nie mamy problemów z testami
automatycznymi, więc nie mam możliwości przetestować tego osobiście.
Przejrzałem użycia obu podejrzanych buforów i nie bardzo widzę, gdzie mogło
by to się sypać. Mógłbyś przetestować patch z załącznika? Nie mam więcej
pomysłów (poz
Cześć,
On Thursday, 12 December 2013 at 05:34, Tomasz Wasilczyk wrote:
> Ciężko to zdebugować, bo pthread miesza na stosie (użycie sigsetjmp).
Udało mi się znowu dość powtarzalnie wywołać ten błąd na Fedorze
19/i686 przy budowaniu paczki z 1.12.0-rc3.
> Czy przy kompilacji były jakiekolwiek błęd
Niestety, nie jestem w stanie zreprodukować tego błędu.
System mam zainstalowany z:
http://ftp.pbone.net/pub/fedora/linux/development/rawhide/i386/os/images/boot.iso
Jedyna opcja do configure: "--with-pthread=yes".
$uname -a
Linux localhost.localdomain 3.13.0-0.rc3.git1.2.fc21.i686 #1 SMP Tue
Ciężko to zdebugować, bo pthread miesza na stosie (użycie sigsetjmp).
Czy przy kompilacji były jakiekolwiek błędy? Jakie flagi do configure
użyłeś (zgaduję, że m.in. --with-pthread=yes). Możesz sprawdzić, czy te
makra są zdefiniowane: __GNUC__, __EXCEPTIONS, __cplusplus (tuż przed
includowanie
Cześć,
On Tuesday, 12 November 2013 at 22:35, Wojtek Kaniewski wrote:
> Szczegóły pod adresem http://libgadu.net/releases/1.12.0-rc1.html
Próbuję właśnie zbudować nową paczkę dla Fedory i o ile na F20 buduje
się bez problemów i testy przechodzi, o tyle na wersji rozwojowej
(Rawhide/F21) dostaję s
13 matches
Mail list logo
