search

markcox / libproxy

Automatically exported from code.google.com/p/libproxy
GNU Lesser General Public License v2.1
0 stars 0 forks source link

Crash when trying to bypass proxy #142

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I get this crash when my application try to access local (same host) URLs when 
HTTP proxies are defined in the configuration.

#0  0x00110832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00736651 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x00739a82 in *__GI_abort () at abort.c:92
#3  0x0072f718 in *__GI___assert_fail (assertion=0xd48dba "obj != __null", 
    file=0xd48d70 "/home/zeenix/downloads/gnome2/libproxy-0.4.6/libmodman/module_manager.hpp", line=58, 
    function=0xd48de0 "std::vector<T*, std::allocator<T*> > libmodman::module_manager::get_extensions() const [with T = libproxy::network_extension]")
    at assert.c:81
#4  0x00d355a6 in std::vector<libproxy::network_extension*, 
std::allocator<libproxy::network_extension*> > 
libmodman::module_manager::get_extensions<libproxy::network_extension>() const 
() from /opt/gnome2/lib/libproxy.so.1
#5  0x00d32268 in libproxy::proxy_factory::_get_proxies(libproxy::url*, 
std::vector<std::string, std::allocator<std::string> >&) ()
   from /opt/gnome2/lib/libproxy.so.1
#6  0x00d31fa4 in libproxy::proxy_factory::get_proxies(std::string) ()
   from /opt/gnome2/lib/libproxy.so.1
#7  0x00d33c31 in px_proxy_factory_get_proxies ()
   from /opt/gnome2/lib/libproxy.so.1
#8  0x00cd6df2 in get_proxy_for_uri_via_libproxy (
    proxy_uri_resolver=0x8557320, uri=0x8526980, cancellable=0xb7503780, 
    proxy_uri=0x85269a8) at soup-proxy-resolver-gnome.c:453
#9  get_proxy_uri_sync (proxy_uri_resolver=0x8557320, uri=0x8526980, 
    cancellable=0xb7503780, proxy_uri=0x85269a8)
    at soup-proxy-resolver-gnome.c:570
#10 0x00cd71d9 in libproxy_threadpool_func (user_data=0x85269a0, 
    thread_data=0x0) at soup-proxy-resolver-gnome.c:525
#11 0x00684fe4 in g_thread_pool_thread_proxy (data=0x82b93c8)
    at gthreadpool.c:319
#12 0x0068309f in g_thread_create_proxy (data=0xb75035c0) at gthread.c:1897
#13 0x005b196e in start_thread (arg=0xb4cfab70) at pthread_create.c:300
#14 0x007d9a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Original issue reported on code.google.com by zee...@gmail.com on 29 Sep 2010 at 1:46

GoogleCodeExporter commented 9 years ago 
Is it possible to document the platform/compiler/cpu/etc. you are running on. 
Also a run with _PX_DEBUG=1 and _MM_DEBUG=1 could help.

Original comment by nicolas.dufresne@gmail.com on 30 Sep 2010 at 9:03

GoogleCodeExporter commented 9 years ago

Original comment by nicolas.dufresne@gmail.com on 7 Nov 2010 at 2:15

GoogleCodeExporter commented 9 years ago 
The information was provided to you on IRC a LONG time ago so I didn't think I 
needed to provide it here as well. Anyway, here is our conversation:

<stormer> [23:59:53] zeenix: could you remind what 
platform/distro/compiler/cpu/etc you are running on ?
<zeenix> [00:05:52] stormer: ubuntu, x86
<zeenix> [00:06:04] stormer: compiler = gcc
<stormer> [00:06:22] do you have NetworkManager ?
<zeenix> [00:06:24] $ uname -a
<zeenix> [00:06:24] Linux codecamp 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 
14:17:33 UTC 2010 i686 GNU/Linux
<zeenix> [00:06:27] stormer: yes
<zeenix> [00:06:37] stormer: the one in ubuntu i guess
<stormer> [00:06:51] that looks like a normal platform
<zeenix> [00:06:58] it very much is :)
<stormer> [00:07:32] there must be a difference, otherwise more people would 
have this issue
<stormer> [00:08:45] zeenix: can you paste bin a run with _MM_DEBUG=1 
_PX_DEBUG=1 proxy http://test.com:80
<zeenix> [00:09:49] stormer: with the proxy config. that allows me to reproduce 
the issue?
<stormer> [00:10:07] yep, while reproducing the issue
<zeenix> [00:10:37] hmm.. hopefully only the proxy config is needed, not the 
proxy to be actually there
<stormer> [00:10:53] you don't need the proxy
<stormer> [00:11:18] libproxy is about reading the proxy configuration, running 
the tool proxy should do just like running your app
<stormer> [00:11:32] (hopeffuly)
<zeenix> [00:11:57] http://pastebin.com/spam.php?i=jUMpyVNb
<stormer> [00:14:04] so it works outside your app :(
<stormer> [00:14:49] zeenix: can your confirm, your running an app, that 
depends on libsoup, which depends on libproxy
<zeenix> [00:15:35] yes
<stormer> [00:24:29] zeenix: the thing is that this bug was fixed month ago 
with 
http://code.google.com/p/libproxy/source/diff?spec=svn618&r=618&format=side&path
=/trunk/libproxy/extension_network.hpp
<stormer> [00:25:41] So I have a really hard time to figure-out why it pops 
again
<zeenix> [00:28:49] hmm..
<stormer> [00:33:21] zeenix: what version of Ubuntu is this ? Is libproxy 0.4.6 
the default ?
<zeenix> [00:33:44] who said i'm using libproxy from Ubuntu :)
<zeenix> [00:33:57] i'm using jhbuild for gnome stuff
<zeenix> [00:34:02] sorry, i should have mentioned
<stormer> [00:34:33] do you have a package named libmodman installed ?
<zeenix> [00:34:41] $ pkg-config --modversion libproxy-1.00.4.6
<zeenix> [00:35:36] libmodman.so
<zeenix> [00:35:40] is there
<zeenix> [00:35:51] in ${PREFIX}/lib/
<stormer> [00:36:50] well the one in your jhbuild tree should be fine, but if 
you are using one from the system, this may go wrong, but again I broke 
libmodman ABI in 0.4.6, so I don't think this is the issue
<stormer> [00:42:21] I'm running jhbuild update, but I last time it did not 
allow me to reproduce, what application/uri is triggering the assertion ?
<zeenix> [00:51:54] stormer: my own: rygel
<stormer> [00:52:40] and what URI rygel tries to load ?
<zeenix> [00:52:50] its own :)
<zeenix> [00:53:01] stormer: rygel has both server and renderer
<zeenix> [00:53:42] so in the control-point app (gupnp-av-cp) i choose to play 
a URI offered by rygel's server-side to rygel's renderer
<stormer> [00:54:17] fair, now what this URI looks like ? (any sample would be 
fine)
<zeenix> [00:55:28] 
http://172.21.36.34:46488/RygelHTTPServer/Tracker/item/QWxsTXVzaWMsdXJuOnV1aWQ6N
zY0OWQyZGItMTM0MC1mMjc3LTdlODctNmMwM2I4ZDAwYTgy
<stormer> [00:57:15] 172.21.36.34 is your local network right ?
<zeenix> [00:59:18] yes
<stormer> [01:16:27] oki, I never ran any test on the ignore code, it's a 
disaster
<stormer> [01:26:07] DimStar, npmccallum: While trying to find a way to 
reproduce zeenix crash, I discovered that the ignore code is mad, if the forth 
digit of an IP is lower then 24, it get ignored
<stormer> [20:19:42] npmccallum, DimStar: I've fix URL stuff on win32, please 
review last 4 commit in 
http://git.collabora.co.uk/?p=user/nicolas/libproxy.git;a=summary
<stormer> [20:20:25] nmake test should now work for all with those, but I only 
tested on MSVC 2010

Original comment by zee...@gmail.com on 7 Nov 2010 at 2:29

GoogleCodeExporter commented 9 years ago 
I've been able to reproduce using Debian sqeeze. This looks like a GCC 4.4 bug 
since I can't reproduce on GCC 4.5. I'm posting a patch here that will 
workaround the issue for distros stuck with this GCC bug, but has this is not 
type safe I won't push this upstream (I'm still open to any type safe solution):

diff --git a/libmodman/module_manager.hpp b/libmodman/module_manager.hpp
index f221bff..045bd81 100644
--- a/libmodman/module_manager.hpp
+++ b/libmodman/module_manager.hpp
@@ -51,7 +51,8 @@ public:
                        vector<base_extension*> extlist = it->second;

                        for (size_t i=0 ; i < extlist.size() ; i++) {
-                               T* obj = dynamic_cast<T*>(extlist[i]);
+                               //T* obj = dynamic_cast<T*>(extlist[i]);
+                               T* obj = (T*)(extlist[i]);
                                if (obj)
                                        retlist.push_back(obj);

Original comment by nicolas.dufresne@gmail.com on 4 Jan 2011 at 4:44