Bug 48908 – crash in px_proxy_factory_get_proxies

• Component: JavaScriptCore
• Status: RESOLVED INVALID

Per the downstream bug report at Ubuntu's Launchpad (see URL: tag for link to downstream bug report) webkit is crashing in the proxy PAC parser:

#0 __strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:39
#1 0x04c2f252 in _run (self=0x98e5788, pac=0x983f2f0, url=0x990e988)
    at pacrunner_webkit.c:197
#2 0x00dafb52 in px_proxy_factory_get_proxies (self=0x984ee80,
    url=0x98e82d8 "http://weather.noaa.gov/cgi-bin/mgetmetar.pl?cccc=CYGK")
    at proxy.c:401
#3 0x00a9fdb2 in ?? () from /usr/lib/libsoup-gnome-2.4.so.1
#4 0x00aa0199 in ?? () from /usr/lib/libsoup-gnome-2.4.so.1
#5 0x007633d4 in g_thread_pool_thread_proxy (data=0x9854df8)
    at /build/buildd/glib2.0-2.26.0/glib/gthreadpool.c:319
#6 0x0076148f in g_thread_create_proxy (data=0x9906bb0)
    at /build/buildd/glib2.0-2.26.0/glib/gthread.c:1897
#7 0x00e39cc9 in start_thread (arg=0xb2fbeb70) at pthread_create.c:304
#8 0x009d56ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

[Andre Klapper]

The trace is missing libsoup symbols.

(In reply to comment #1)
> The trace is missing libsoup symbols.

Indeed, but seriously, is it really unclear about what is failing in px_proxy_factory_get_proxies() without the libsoup symbols?  It's not like the call to px_proxy_factory_get_proxies() is all that complicated.

In any case, I have installed the libsoup debug symbols.  It shouldn't take very long to get another crash (it happens dozens of times a day) and get another stack trace for you.

So here's the stack trace with libsoup symbols:

#0  __strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:39
#1  0x00ed5252 in _run (self=0x933e7e0, pac=0x933e7f0, url=0x9424fd8)
    at pacrunner_webkit.c:197
#2  0x00c36b52 in px_proxy_factory_get_proxies (self=0x9314340, 
    url=0x9488838 "http://weather.noaa.gov/mgetmetar.php?cccc=CYYZ")
    at proxy.c:401
#3  0x00a9cdb2 in get_proxy_for_uri_via_libproxy (
    proxy_uri_resolver=0x9318650, uri=0x93d4240, cancellable=0x9447d40, 
    proxy_uri=0x945ab08) at soup-proxy-resolver-gnome.c:453
#4  get_proxy_uri_sync (proxy_uri_resolver=0x9318650, uri=0x93d4240, 
    cancellable=0x9447d40, proxy_uri=0x945ab08)
    at soup-proxy-resolver-gnome.c:570
#5  0x00a9d199 in libproxy_threadpool_func (user_data=0x945ab00, 
    thread_data=0x0) at soup-proxy-resolver-gnome.c:525
#6  0x002e13d4 in g_thread_pool_thread_proxy (data=0x931a1a8)
    at /build/buildd/glib2.0-2.26.0/glib/gthreadpool.c:319
#7  0x002df48f in g_thread_create_proxy (data=0x939fff8)
    at /build/buildd/glib2.0-2.26.0/glib/gthread.c:1897
#8  0x0047acc9 in start_thread (arg=0xb4c75b70) at pthread_create.c:304
#9  0x0093f69e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

And what I hope is some useful data:

(gdb) frame 2
#2  0x00c36b52 in px_proxy_factory_get_proxies (self=0x9314340, 
    url=0x9488838 "http://weather.noaa.gov/mgetmetar.php?cccc=CYYZ")
    at proxy.c:401
401	proxy.c: No such file or directory.
	in proxy.c
(gdb) print self
$1 = (pxProxyFactory *) 0x9314340
(gdb) print *self
$2 = {mutex = {__data = {__lock = 1, __count = 0, __owner = 10518, __kind = 0, 
      __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, 
    __size = "\001\000\000\000\000\000\000\000\026)\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 1}, mm = 0x931acb8, pac = 0x933e7f0, 
  wpad = false}
(gdb) print *self->pac
$3 = {url = 0x933e780, 
  cache = 0x93cdd88 "function FindProxyForURL(url, host) {\n    if (isPlainHostName(host) ||\n\tisInNet(host, \"10.75.22.0\", \"255.255.254.0\") ||\n\tisInNet(host, \"10.23.104.0\", \"255.255.248.0\") ||\n\tisInNet(host, \"192.168.0.0\", "..., expires = 0}

Cheers.

Was the last stacktrace any more useful?

I'm increasing the priority of this bug since it is causing both the gnome-panel's clock and rhythmbox to crash dozens of times a day.

Any ideas on this with the new stack trace?

This bug is very annoying as it's crashing multiple programs here many times a day as they try to use libproxy to determine how to access the Internet.

You asked for a stack trace with symbols and I have attached it, a long time ago.

Is this component of webkit ignored and not maintained?  Please let me know so that I can file a bug with my distro to remove functionality that is depending on it (and buggy/not working as a result of this bug).

On second (or third or is it forty-eleventh now?) look, perhaps this is a bug in libproxy and not webkit.  I will close it until know better.