[dev] [surf] Surf crashes (soup problem?)

2009-12-07 Thread Sandra Snan
Hi, I’ve found a bug, but I don’t know if it’s in libsoup or if it’s
in suckless’ surf, which uses libsoup, or if it’s in some other
library in between (webkit?).

The situation is that I go to http://identi.ca/main/openid
enter my openID uri  (to a server that runs phpMyID version 0.9),
hit RET,
the dialog box from the openID server comes up, I enter correct name and pass,
surf crashes.

I first ran into this with surf release 0.3, and the debian unstable
amd64 package of libsoup2.4-1 version 2.4.1-2,
but I recompiled surf with libsoup from git (december seventh), and
then I tried it with surf from hg tip, too. Same problem with all
three tries. (Stable surf + stable soup, stable surf + git soup, hg
surf + git soup.)

ellen% ldd ./surf|grep soup
libsoup-2.4.so.1 => /usr/lib/libsoup-2.4.so.1 (0x7f8676e1c000)


Here is the error message:

**
libsoup:ERROR:soup-auth-digest.c:378:soup_auth_digest_compute_response:
code should not be reached
zsh: abort  ./surf

The snippet in soup-auth-digest looks like this:
if (qop != SOUP_AUTH_DIGEST_QOP_AUTH)
g_assert_not_reached ();

And here is the stack trace from gdb:

(gdb) bt
#0  0x77abef55 in raise ()
   from /lib/libc.so.6
#1  0x77ac1d90 in abort ()
   from /lib/libc.so.6
#2  0x73f24ad0 in g_assertion_message ()
   from /lib/libglib-2.0.so.0
#3  0x75fb4887 in soup_auth_digest_compute_response () from
/usr/lib/libsoup-2.4.so.1
#4  0x75fb4e3b in ?? ()
   from /usr/lib/libsoup-2.4.so.1
#5  0x75fc578e in soup_message_set_auth ()
   from /usr/lib/libsoup-2.4.so.1
#6  0x75fb7df3 in ?? ()
   from /usr/lib/libsoup-2.4.so.1
#7  0x743994bd in g_closure_invoke ()
   from /usr/lib/libgobject-2.0.so.0
#8  0x743acc8b in ?? ()
   from /usr/lib/libgobject-2.0.so.0
#9  0x743ae032 in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#10 0x743ae503 in g_signal_emit ()
   from /usr/lib/libgobject-2.0.so.0
#11 0x75fd0e26 in soup_session_send_queue_item () from
/usr/lib/libsoup-2.4.so.1
#12 0x75fd25ce in ?? ()
   from /usr/lib/libsoup-2.4.so.1
#13 0x75fd2663 in ?? ()
   from /usr/lib/libsoup-2.4.so.1
#14 0x73eff12a in g_main_context_dispatch ()
---Type  to continue, or q  to quit---
   from /lib/libglib-2.0.so.0
#15 0x73f02988 in ?? ()
   from /lib/libglib-2.0.so.0
#16 0x73f02e5d in g_main_loop_run ()
   from /lib/libglib-2.0.so.0
#17 0x76329af7 in gtk_main ()
   from /usr/lib/libgtk-x11-2.0.so.0
#18 0x0040618f in ?? ()
#19 0x77aababd in __libc_start_main ()
   from /lib/libc.so.6
#20 0x00403bd9 in ?? ()
#21 0x7fffea08 in ?? ()
#22 0x001c in ?? ()
#23 0x0001 in ?? ()
#24 0x7fffec58 in ?? ()
#25 0x in ?? ()



Re: [dev] [surf] Surf crashes (soup problem?)

2009-12-07 Thread Sandra Snan
On Mon, Dec 7, 2009 at 8:23 PM, Dan Winship  wrote:
> mmm... yes, it probably should be
>
>    if (!(qop & SOUP_AUTH_DIGEST_QOP_AUTH))

Tried it, but then the openid login box just keeps popping up again and again.

> could you run surf with WEBKIT_DEBUG=Network and confirm that the Digest
> WWW-Authenticate header sent from identi.ca has qop="auth,auth-int" ?

Yes. The line starts:

WWW-Authenticate: Digest qop="auth-int, auth", realm="phpMyID",

and goes on with my domains and hashes.
It seems to be my openID server that sends it, not identi.ca.



Re: [dev] [surf] Surf crashes (soup problem?)

2009-12-07 Thread Sandra Snan
On Mon, Dec 7, 2009 at 9:44 PM, Sandra Snan  wrote:
> On Mon, Dec 7, 2009 at 8:23 PM, Dan Winship  wrote:
>> mmm... yes, it probably should be
>>
>>    if (!(qop & SOUP_AUTH_DIGEST_QOP_AUTH))
>
> Tried it, but then the openid login box just keeps popping up again and again.

To clarify, that should read “Tried it after your suggestion, but”,
not “Already tried it, but”.



[dev] [dwm] [surf] Classes for surf?

2009-12-08 Thread Sandra Snan
xprop seems to think that the class name is "surf", but here are my dwm rules:
static Rule rules[] = {
/* class  instancetitle   tags mask isfloating */
{ "Iceweasel",  NULL,   NULL,   8,   False },
{ "surf",  NULL,   NULL,   8,   False },
{ "Emacs",  NULL,   NULL,   4,  False },
{ "Totem", NULL,NULL,   32, False},
{ "Tasks", NULL,NULL,   64, False},
};

New Iceweasel windows show up having the fourth tag from the left
regardless of which tags were visible when I first launched it (I
often have many tags visible), but new surf windows just have the tags
that were visible, seemingly ignoring these rules. What am I doing
wrong?
All the other ones work.