Hello Herr Sprickerhof,
First of all thank you for your quick answer. Your last remark
gave me the hint I needed :
It turns out I had a stale libsurf-webext.so in the directory
/usr/local/lib/surf, removing it solved the problem. This is due
to the fact that upstream changed the name of the library from
libsurf-webext.c to webext-surf.c between debian/2.0+git20181009
and debian/2.0+git20201107, which means that a not careful enough
direct use of the Makefile (make install once in each branch, not
separated with a make uninstall) would mean that two versions of
the shared object library (the stale one libsurf-webext.so, and
the new one webext-surf.so) would cohabit in the same directory
/usr/local/lib/surf.
These two shared object libraries would have competing versions of
each symbol, and more specifically two versions of the culprit
symbol webkit_web_initialize_with_user_data() :
- one (libsurf-webext.so) that would have g_variant_get(gv,
"(ii)", &pipein, &pipeout)
- the other (webext-surf.so) that would have g_variant_get(gv,
"i", &sock)
Since in the new version (debian/2.0+git20201107), gv would be
created like this :
gv = g_variant_new("i", spair[1])
surf would work correctly only if the dynamic linking would use
webext-surf.so, and crash if the dynamic linking had chosen
libsurf-webext.so. I have no idea how the choice is made
(alphabetic order of each shared object file maybe ??), but it
seems the dynamic linking systematically chose the stale file
before we removed it.
So the problem was entirely my fault, and a more careful direct
use of the Makefile solved the problem. So I am sorry for having
wasted your time.
However, the stuff I do on my own patched version of surf (that
goes in /usr/local/bin, with the shared object going in
/usr/local/lib/surf/) should have no influence on the Debian
version of surf living in /usr/bin : even when I launched
/usr/bin/surf, the stale library
/usr/local/lib/surf/libsurf-webext.so would be used over
/usr/lib/surf/webext-surf.so ! So a user-compiled shared object
(in /usr/local) would take precedence over a Debian-compiled
version (in /usr), even when the binary is itself in /usr ?
This, in my opinion, is still a bug (albeit a lot less severe and
a lot more subtle, and arguably a different one). What is the next
course of action ?
The symbol webkit_web_initialize_with_user_data() is not called
from surf, but from webkit. So the bug lies not with the surf
package, but probably with the libwebkit2gtk-4.0-37.
So the original bug (surf not starting) can be closed (I have no
idea how to do that). I'll let you tell me whether you agree with
my opinion that webkit should try to resolve
webkit_web_initialize_with_user_data() from /usr/lib/surf and not
from /usr/local/lib/surf when the binary is /usr/bin/surf, and
whether this warrants another bug report (and in which package ) ?
Thank you again for your time reading this long message,
Best regards,
Aymeric Agon-Rambosson
Jochen Sprickerhof <jspri...@debian.org> writes:
* Aymeric Agon-Rambosson <aymeric.a...@yandex.com> [2021-04-27
03:18]:
$ /usr/bin/surf
output :
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728: the
GVariant format string '(ii)' has a type of '(ii)' but the given
value has a type of 'i'
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.728:
g_variant_get: assertion 'valid_format_string (format_string,
TRUE, value)' failed
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729: the
GVariant format string '(ii)' has a type of '(ii)' but the given
value has a type of 'i'
(WebKitWebProcess:94294): GLib-CRITICAL **: 02:49:52.729:
g_variant_get: assertion 'valid_format_string (format_string,
TRUE, value)' failed
web process terminated: crashed
Also, can you check if you have a custom webext-surf.so in your
~/.surf or elsewhere in your ld path?
