From 9144710a34abe4b8c1d1a1a09ae1aaa316a5c72e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 27 Oct 2012 19:59:17 -0400 Subject: [PATCH] blog for the day --- .../assistant/blog/day_116__the_segfault.mdwn | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/design/assistant/blog/day_116__the_segfault.mdwn diff --git a/doc/design/assistant/blog/day_116__the_segfault.mdwn b/doc/design/assistant/blog/day_116__the_segfault.mdwn new file mode 100644 index 0000000000..47633454a1 --- /dev/null +++ b/doc/design/assistant/blog/day_116__the_segfault.mdwn @@ -0,0 +1,25 @@ +Continuing to flail away at this XMPP segfault, which turned out not to be +fixed by bound threads. I managed to make a fairly self-contained and small +reproducible test case for it that does not depend on the network. +Seems the bug is gonna be either in the Haskell binding for GNUTLS, +or possibly in GNUTLS itself. + +Update: John was able to fix it using my testcase! It was a GNUTLS +credentials object that went out of scope and got garbage collected. +I think I was seeing the crash only with the threaded runtime because +it has a separate garbage collection thread. + +---- + +Arranged for the XMPP thread to restart when network connections +change, as well as when the webapp configures it. + +Added an alert to nudge users to enable XMPP. It's displayed after adding a +remote in the cloud. + +[[!img /assistant/xmppnudge.png]] + +---- + +So, the first stage of XMPP is done. But so far all it does is push +notification. Much more work to do here.