[libgadu-devel] logowanie do GG nie działa po TLS
Witam i mam nadzieję, że ktoś tu jeszcze żyje. :)
Otóż od jakiegoś czasu nie działa logowanie do GG po TLS.
System: Fedora 25
pidgin-2.11.0
libgadu-1.12.1
Oto log z pidgina (nr konta częściowo zaiksowany):
===
(15:08:20) account: Connecting to account 18x.
(15:08:20) connection: Connecting. gc = 0x5581a1847b80
(15:08:20) gg: Trying to retrieve address from gg appmsg service
(15:08:20) gg: ggp_to_gg_status: Requested status = available
(15:08:20) gg: Requested encryption type: opportunistic_tls
(15:08:20) gg: TLS enabled: 1
(15:08:20) gg: ** gg_login(0x5581a184a9c0: [uin=18x, async=1, ...]);
(15:08:20) gg: ** gg_watch_fd(0x5581a184a790);
(15:08:20) gg: // gg_watch_fd() GG_STATE_RESOLVE_HUB_ASYNC
(15:08:20) gg: ** gg_resolver_pthread_start(0x5581a184a790, 0x5581a184a848,
"appmsg.gadu-gadu.pl");
(15:08:20) gg: // gg_resolver_pthread_start() 0x5581a17d0a20
(15:08:20) gg: ** gg_event_free(0x5581a18295e0);
(15:08:20) gg: login_handler: session: check = 2; state = 62;
(15:08:20) gg: unknown state = 62
(15:08:20) gg: ** gg_watch_fd(0x5581a184a790);
(15:08:20) gg: // gg_watch_fd() GG_STATE_RESOLVING_HUB
(15:08:20) gg: // gg_watch_fd() GG_STATE_CONNECT_HUB
(15:08:20) gg: // gg_watch_fd() connecting to 91.214.239.49:80
(15:08:20) gg: ** gg_connect(91.214.239.49, 80, 1);
(15:08:20) gg: // gg_connect() connect() in progress
(15:08:20) gg: login_handler: session->fd = 8
(15:08:20) gg: login_handler: session: check = 1; state = 5;
(15:08:20) gg: GG_EVENT_NONE
(15:08:20) gg: ** gg_event_free(0x5581a17f41d0);
(15:08:20) gg: login_handler: session: check = 1; state = 5;
(15:08:20) gg: GG_STATE_CONNECTING_HUB
(15:08:20) gg: ** gg_watch_fd(0x5581a184a790);
(15:08:20) gg: // gg_watch_fd() GG_STATE_CONNECTING_HUB
(15:08:20) gg: // gg_watch_fd() GG_STATE_SEND_HUB
(15:08:20) gg: // sending http query:
GET
/appsvc/appmsg_ver10.asp?fmnumber=18x=2=0=11.3.45.10771=2=1
HTTP/1.0
Connection: close
Host: appmsg.gadu-gadu.pl
(15:08:20) gg: login_handler: session->fd = 8
(15:08:20) gg: login_handler: session: check = 2; state = 71;
(15:08:20) gg: GG_EVENT_NONE
(15:08:20) gg: ** gg_event_free(0x5581a1829800);
(15:08:20) gg: login_handler: session: check = 2; state = 71;
(15:08:20) gg: unknown state = 71
(15:08:20) gg: ** gg_watch_fd(0x5581a184a790);
(15:08:20) gg: // gg_watch_fd() GG_STATE_READING_HUB
(15:08:20) gg: login_handler: session->fd = 8
(15:08:20) gg: login_handler: session: check = 2; state = 71;
(15:08:20) gg: GG_EVENT_NONE
(15:08:20) gg: ** gg_event_free(0x5581a0d9ac00);
(15:08:20) gg: login_handler: session: check = 2; state = 71;
(15:08:20) gg: unknown state = 71
(15:08:20) gg: ** gg_watch_fd(0x5581a184a790);
(15:08:20) gg: // gg_watch_fd() GG_STATE_READING_HUB
(15:08:20) gg: // received http reply:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 31 Jan 2017 14:08:20 GMT
Connection: close
26713 0 91.214.237.48:8074 91.214.237.48
(15:08:20) gg: reply=26713, host="91.214.237.48:8074"
(15:08:20) gg: // gg_watch_fd() GG_STATE_RESOLVE_GG_ASYNC
(15:08:20) gg: ** gg_resolver_pthread_start(0x5581a184a790, 0x5581a184a848,
"91.214.237.48");
(15:08:20) gg: // gg_resolver_pthread_start() 0x5581a184e2b0
(15:08:20) gg: login_handler: session->fd = 8
(15:08:20) gg: login_handler: session: check = 2; state = 43;
(15:08:20) gg: System message:
(15:08:20) gg: ** gg_event_free(0x5581a1829800);
(15:08:20) gg: login_handler: session: check = 2; state = 43;
(15:08:20) gg: GG_STATE_RESOLVING_GG
(15:08:20) gg: ** gg_watch_fd(0x5581a184a790);
(15:08:20) gg: // gg_watch_fd() GG_STATE_RESOLVING_GG
(15:08:20) gg: // gg_watch_fd() GG_STATE_CONNECT_GG
(15:08:20) gg: resolver_index=0, connect_index=0, connect_port={8074,443}
(15:08:20) gg: // gg_watch_fd() connecting to 91.214.237.48:8074
(15:08:20) gg: ** gg_connect(91.214.237.48, 8074, 1);
(15:08:20) gg: // gg_connect() connect() in progress
(15:08:20) gg: login_handler: session->fd = 8
(15:08:20) gg: login_handler: session: check = 1; state = 6;
(15:08:20) gg: GG_EVENT_NONE
(15:08:20) gg: ** gg_event_free(0x5581a178c6e0);
(15:08:20) gg: login_handler: session: check = 1; state = 6;
(15:08:20) gg: GG_STATE_CONNECTING_GG
(15:08:20) gg: ** gg_watch_fd(0x5581a184a790);
(15:08:20) gg: // gg_watch_fd() GG_STATE_CONNECTING_GG
(15:08:20) gg: // gg_watch_fd() connected
(15:08:20) gg: // gg_watch_fd() GG_STATE_TLS_NEGOTIATION
(15:08:20) gg: // gg_watch_fd() GG_STATE_TLS_NEGOTIATION
(15:08:20) gg: // gg_watch_fd() TLS handshake error: -15, An unexpected TLS
packet was received.
(15:08:20) gg: login_handler: session->fd = -1
(15:08:20) gg: login_handler: session: check = 1; state = 0;
(15:08:20) GLib: Source ID 1227 was not found when attempting to remove it
(15:08:20) connection: Connection error on 0x5581a1847b80 (reason: 0
description: Connection failed)
(15:08:20) gg: ** gg_event_free(0x5581a178c7f0);
(15:08:20) account: Disconnecting account 18x (0x5581a0d70580)
(15:08:20) connection: Disconnecting connection 0x5581a1847b80
(15:08:20) gg: ggp_to_gg_status: Requested status = available
Re: [libgadu-devel] Segmentation fault w teście resolvera (było: Re: libgadu 1.12.0-rc1)
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 raz), więc raczej nie problem sprzętowy. Jak budujesz? Może to kwestia użytych flag kompilatora. 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 (poza debug-printfowaniem). 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. Pozdrawiam, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] [PATCH] błąd kompilacji test/automatic/hash.c (było: Re: libgadu 1.12.0-rc3)
Cześć, On Wednesday, 07 May 2014 at 22:14, Wojtek Kaniewski wrote: [...] Szczegóły pod adresem http://libgadu.net/releases/1.12.0-rc3.html Na Fedorze make check wywala się z błędem kompilacji test/automatic/hash.c: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -DGG_IGNORE_DEPRECATED -I../../include -I../../test -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wall -Wextra -Wmissing-prototypes -Wno-unused-parameter -Waggregate-return-Wdeclaration-after-statement -Wundef -Wcast-align -Wpointer-arith -I/usr/include/p11-kit-1 -c -o hash.o hash.c In file included from /usr/include/fcntl.h:302:0, from ../../include/fileio.h:32, from hash.c:26: In function 'open', inlined from 'gg_mkstemp' at hash.c:41:7, inlined from 'test_file_hash' at hash.c:126:5, inlined from 'main' at hash.c:177:3: /usr/include/bits/fcntl2.h:50:4: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments __open_missing_mode (); ^ make[4]: *** [hash.o] Error 1 make[4]: Leaving directory `/builddir/build/BUILD/libgadu-1.12.0-rc3/test/automatic' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/builddir/build/BUILD/libgadu-1.12.0-rc3/test/automatic' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/libgadu-1.12.0-rc3/test/automatic' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/libgadu-1.12.0-rc3/test' make: *** [check-recursive] Error 1 Załączam łatkę, która to naprawia dla mnie. Pozdrawiam, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations diff -up libgadu-1.12.0-rc3/test/automatic/hash.c.open libgadu-1.12.0-rc3/test/automatic/hash.c --- libgadu-1.12.0-rc3/test/automatic/hash.c.open 2014-05-06 21:15:17.0 +0200 +++ libgadu-1.12.0-rc3/test/automatic/hash.c2014-05-23 11:58:04.167842634 +0200 @@ -38,7 +38,7 @@ gg_mkstemp(char *path) if (strcmp(mktemp(path), ) == 0) ret = -1; else /* XXX: O_CREAT shouldn't be necessary */ - ret = open(path, O_EXCL | O_RDWR | O_CREAT); + ret = open(path, O_EXCL | O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); #endif umask(old_umask); ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] Segmentation fault w teście resolvera (było: Re: libgadu 1.12.0-rc1)
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łędy? Jakie flagi do configure użyłeś (zgaduję, że m.in. --with-pthread=yes). Flagi configure: ./configure --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-silent-rules --disable-static --without-openssl --with-pthread Błędów kompilacji nie było. Wywołanie libtoola dla tego pliku wygląda tak: /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include-I.. -I../include -DGG_IGNORE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -Wextra -Wmissing-prototypes -Wno-unused-parameter -Waggregate-return -Wdeclaration-after-statement -Wundef -Wcast-align -Wpointer-arith -I/usr/include/p11-kit-1 -c -o libgadu_la-resolver.lo `test -f 'resolver.c' || echo './'`resolver.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I.. -I../include -DGG_IGNORE_DEPRECATED -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -grecord-gcc-switches -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wall -Wextra -Wmissing-prototypes -Wno-unused-parameter -Waggregate-return -Wdeclaration-after-statement -Wundef -Wcast-align -Wpointer-arith -I/usr/include/p11-kit-1 -c resolver.c -fPIC -DPIC -o .libs/libgadu_la-resolver.o Możesz sprawdzić, czy te makra są zdefiniowane: __GNUC__, __EXCEPTIONS, __cplusplus (tuż przed includowaniem pthread.h w resolver.c). __GNUC__ i __EXCEPTIONS są zdefiniowane, __cplusplus nie. Spróbuj zaaplikować łatkę z załącznika, rozwieje parę wątpliwości: - czy wątek jest zabijany w jakimś niespodziewanym momencie (patrz linijka pthread_setcancelstate i jej komentarz) - ile razy jest wywoływany gg_resolver_pthread_cleanup - zagnieżdżone pthread_cleanup_push nie powinny robić szkód, ale nigdy nie wiadomo Łatka wprawdzie już się nie daje nałożyć, ale pomaga dodanie pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL); w linii 535. Bez tego mniej więcej co 3 wywołanie testu automatic/resolver kończy się segmentation fault (załączam log z poprawnego i nieudanego wykonania testu). gdb pokazuje: (gdb) run Starting program: /builddir/build/BUILD/libgadu-1.12.0-rc3/test/automatic/./resolver [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/libthread_db.so.1. *** TEST 1 *** Setting global fork resolver Setting global pthread resolver Setting global custom resolver Setting global default resolver Testing local default resolver ** gg_login(0xd61c: [uin=1, async=1, ...]); ** gg_watch_fd(0x804c008); // gg_watch_fd() GG_STATE_RESOLVE_HUB_ASYNC ** gg_resolver_pthread_start(0x804c008, 0x804c094, appmsg.gadu-gadu.pl); [New Thread 0xf7b0bb40 (LWP 3952)] // gg_resolver_pthread_start() 0x804c1d8 ** gg_event_free(0x804c198); ** gg_free_session(0x804c008); ** gg_resolver_pthread_cleanup(0x804c094 [0x804c1d8], 1); Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf7b0bb40 (LWP 3952)] 0xf7fa7480 in free@plt () from /builddir/build/BUILD/libgadu-1.12.0-rc3/src/.libs/libgadu.so.3 (gdb) where #0 0xf7fa7480 in free@plt () from /builddir/build/BUILD/libgadu-1.12.0-rc3/src/.libs/libgadu.so.3 #1 0xf7fc3e51 in gg_resolver_cleaner (data=0xf7b0b35c) at resolver.c:69 #2 __pthread_cleanup_routine (__frame=synthetic pointer) at /usr/include/pthread.h:602 #3 gg_resolver_run (fd=optimized out, hostname=optimized out, pthread=pthread@entry=1) at resolver.c:287 #4 0xf7fc3e86 in gg_resolver_pthread_thread (arg=0x804c1d8) at resolver.c:540 #5 0xf7e4e9da in start_thread () from /lib/libpthread.so.0 #6 0xf7d80bfe in clone () from /lib/libc.so.6 Pozdrawiam, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations [mockbuild@amaterasu automatic]$ ./resolver *** TEST 1 *** Setting global fork resolver Setting global pthread resolver Setting global custom resolver Setting global default resolver Testing local default resolver ** gg_login(0xffe0b23c: [uin=1, async=1, ...]); ** gg_watch_fd(0x8753008); // gg_watch_fd() GG_STATE_RESOLVE_HUB_ASYNC ** gg_resolver_pthread_start(0x8753008,
[libgadu-devel] Segmentation fault w teście resolvera (było: Re: libgadu 1.12.0-rc1)
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ę segmentation fault przy teście resolvera (ale
tylko na x86_32):
$ make check
[...]
Testing local pthread resolver
** gg_login(0xffd6338c: [uin=1, async=1, ...]);
** gg_watch_fd(0x82be028);
// gg_watch_fd() GG_STATE_RESOLVE_HUB_ASYNC
** gg_resolver_pthread_start(0x82be028, 0x82be0b4,
appmsg.gadu-gadu.pl);
// gg_resolver_pthread_start() 0x82be1f0
** gg_event_free(0x82be1b0);
** gg_free_session(0x82be028);
Testing global default resolver in HTTP
= -BEGIN-HTTP-QUERY-
GET /test HTTP/1.0
= -END-HTTP-QUERY-
** gg_resolver_pthread_start(0x82be028, 0x82be074, test);
// gg_resolver_pthread_start() 0x82be1f0
// gg_http_connect() resolver = 0x82be1f0
/bin/sh: line 5: 31811 Segmentation fault (core dumped) ${dir}$tst
FAIL: resolver
$ gdb resolver core.30869
GNU gdb (GDB) Fedora 7.6.50.20130731-16.fc21
[...]
This GDB was configured as i686-redhat-linux-gnu.
[...]
Reading symbols from
/builddir/build/BUILD/libgadu-1.12.0-rc1/test/automatic/resolver...done.
[New LWP 30881]
[New LWP 30869]
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/libthread_db.so.1.
Core was generated by `./resolver'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0xf770e480 in free@plt () from
/builddir/build/BUILD/libgadu-1.12.0-rc1/src/.libs/libgadu.so.3
(gdb) where
#0 0xf770e480 in free@plt () from
/builddir/build/BUILD/libgadu-1.12.0-rc1/src/.libs/libgadu.so.3
#1 0xf772aa23 in gg_resolver_cleaner (data=0xf6db8288) at resolver.c:69
#2 __pthread_cleanup_routine (__frame=synthetic pointer) at
/usr/include/pthread.h:622
#3 gg_resolver_run (fd=optimized out, hostname=optimized out,
pthread=pthread@entry=1) at resolver.c:283
#4 0xf772aa56 in gg_resolver_pthread_thread (arg=0x8e571f0) at resolver.c:524
#5 0xf75bafda in start_thread () from /lib/libpthread.so.0
#6 0xf74e919e in clone () from /lib/libc.so.6
Jakieś pomysły, jak to zdebugować?
Pozdrawiam,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
___
libgadu-devel mailing list
libgadu-devel@lists.ziew.org
http://lists.ziew.org/mailman/listinfo/libgadu-devel
Re: [libgadu-devel] linkowanie z openssl
On Sunday, 06 December 2009 at 11:14, Wojtek Kaniewski wrote: Dominik 'Rathann' Mierzejewski pisze: Fakt, że libgadu linkuje openssl sprawia kłopoty licencyjne aplikacjom, które używają libgadu i są na licencji GPL (pidgin, ekg2, gg2). Czy dałoby się dodać obsługę np. gnutls? Mam to ma mojej liście TODO, ale póki co, to nie ma sensu. O ile mi wiadomo, w chwili obecnej serwery i tak nie obsługują SSL/TLS, więc ten kod nie jest nikomu do niczego potrzebny. Po prostu w specu nie włączaj (albo wyłączaj) obsługę OpenSSL, o ile już tego nie robisz. Tak właśnie zrobiłem, dzięki za informację. Pozdrawiam, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
[libgadu-devel] nowe wydanie?
Witam. Kiedy planowane jest wydanie następnej wersji? Nowe Kadu (0.6.0-alpha1) wymaga wersji z CVS, a nie chciałbym paczkować wersji rozwojowej jeśli nie ma planów wydania kolejnej wersji w rozsądnym czasie. Pozdrawiam, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations ___ libgadu-devel mailing list libgadu-devel@lists.ziew.org http://lists.ziew.org/mailman/listinfo/libgadu-devel
