file:/// etc
Aron Griffis
Ubuntu Karmic so I have version 0.2.3 installed to satisfy system
dependencies. However I've also built 0.3.1+ from subversion so
I'm using that for my testing
I have no proxy environment variables set and I don't have an
/etc/proxy.conf or ~/.proxy.conf. I have the following gconf
settings:
$ gconftool-2 -a /system/proxy
autoconfig_url = file:///home/agriffis/skel/proxy.pac
ftp_port = 0
mode = auto
secure_port = 0
secure_host =
socks_host =
socks_port = 0
ftp_host =
This allows Chromium to use the proxy.pac so I know it's set
correctly. However I'm interested in using libproxy to test
changes to my proxy.pac. I thought I could use the "proxy" tool
for this, but
$ ./autogen.sh
...
Modules to build...
direct : yes
envvar : yes
file : yes
gnome : yes
kde4 : no
wpad : yes
networkmanager : yes
mozjs : no
webkit : yes
Bindings to build...
python : yes
java : no
dotnet : no
$ make
$ cd src/bin
$ ./proxy
An unknown error occurred!
I think the problem is that libproxy hardcodes MODULEDIR so
there's no way to use it without installing it. It would be nice
if that could be overridden, for example with an environment
variable PX_MODULEDIR
Some other questions:
1. Is there any documentation for the content of proxy.conf?
2. Are there any flags or environment variables that can be set
to debug libproxy as it traverses modules?
Thanks,
Aron
Dominique Leuenberger
I'm trying to use libproxy with a local PAC file. I'm running
Ubuntu Karmic so I have version 0.2.3 installed to satisfy system
dependencies. However I've also built 0.3.1+ from subversion so
I'm using that for my testing
file:// has been added in the 0.3.0 branch to be valid. So the 0.2.3 is not able to use them. 0.3.1 should work fine though (It's used in the test suite for example).
the plugin path is compiled into the library and as long as you don't make install them (and possibly launch ldconfig to find the new priorities...) it will not find any plugin and as such this error happens (well: not really "unknwon error" I have to recon :) )
I think the problem is that libproxy hardcodes MODULEDIR so
there's no way to use it without installing it. It would be nice
if that could be overridden, for example with an environment
variable PX_MODULEDIR
Some other questions:
1. Is there any documentation for the content of proxy.conf?
I do not think so at the moment. In fact, 0.3.0 and 0.3.1 don't even read the conf file :( This has been fixed in SVN already though.
the config file module is very limited. I'll consider adding a proxy.conf.in to have part of the installation routines with documented entries. Thanks for bringing this up. Out of my head I know of those entries:
/etc/proxy.conf
# proxy
# can have values like: http://proxy:3128 , wpad:// or pac+http://uri.to/script.pac
proxy=http://127.0.0.1:3128
ignore=127.0.0.0/8
# config_order
# You can define an order in which the plugins should be tried to be loaded. Typically, the first plugin
# that returns "true", so replies it did get a configuration, will be used.
config_order=USER,SESSION,SYSTEM,config_envvar,config_wpad,config_direct
2. Are there any flags or environment variables that can be set
to debug libproxy as it traverses modules?
Not yet, but this certainly does not sound like a very bad idea. At this time it's impossible to say which plugin was used.
Dominique
Aron Griffis
> the plugin path is compiled into the library and as long as you don't make
> install them (and possibly launch ldconfig to find the new priorities...) it
> will not find any plugin and as such this error happens (well: not really
> "unknwon error" I have to recon :) )
Okay, that's pretty much what I said:
> > I think the problem is that libproxy hardcodes MODULEDIR so
> > there's no way to use it without installing it. It would be nice
> > if that could be overridden, for example with an environment
> > variable PX_MODULEDIR
>
> Some other questions:
> >
> > 1. Is there any documentation for the content of proxy.conf?
> >
>
> I do not think so at the moment. In fact, 0.3.0 and 0.3.1 don't even read
> the conf file :( This has been fixed in SVN already though.
>
> the config file module is very limited. I'll consider adding a
> proxy.conf.into have part of the installation routines with documented
> entries. Thanks
> for bringing this up. Out of my head I know of those entries:
>
> /etc/proxy.conf
> # proxy
> # can have values like: http://proxy:3128 , wpad:// or pac+
> http://uri.to/script.pac
> proxy=http://127.0.0.1:3128
> ignore=127.0.0.0/8
>
> # config_order
> # You can define an order in which the plugins should be tried to be loaded.
> Typically, the first plugin
> # that returns "true", so replies it did get a configuration, will be used.
> config_order=USER,SESSION,SYSTEM,config_envvar,config_wpad,config_direct
Yes, the config file isn't very useful without documentation. No
wonder it was broken in 0.3.0 and 0.3.1 and nobody knew. ;-)
> > 2. Are there any flags or environment variables that can be set
> > to debug libproxy as it traverses modules?
>
> Not yet, but this certainly does not sound like a very bad idea. At this
> time it's impossible to say which plugin was used.
>
> Hope this helps you a little bit.
Yes, thanks. If I get approval from my company then I'll send
some patches.
Thanks,
Aron
Aron Griffis
>
> >
> > I'm trying to use libproxy with a local PAC file. I'm running
> > Ubuntu Karmic so I have version 0.2.3 installed to satisfy system
> > dependencies. However I've also built 0.3.1+ from subversion so
> > I'm using that for my testing
> >
>
> file:// has been added in the 0.3.0 branch to be valid. So the 0.2.3 is not
> able to use them. 0.3.1 should work fine though (It's used in the test suite
> for example).
Okay, I've gotten it working with the subversion build once
I installed to /usr/local. Thanks for the help.
Unfortunately it segfaults on my proxy.pac. Note my proxy.pac
works fine in firefox, IE and chrome. Without revealing the
content of the proxy.pac, which is private, here is a series of
tests that demonstrates the problem:
----------------------------------------------------------------------
proxy.pac:
| function FindProxyForURL(url, host) { return "PROXY yayitworked:8080"; }
$ proxy http://test.test/
http://yayitworked:8080
----------------------------------------------------------------------
proxy.pac:
| ip = dnsResolve("google.com.");
| function FindProxyForURL(url, host) { return "PROXY yayitworked:8080"; }
$ proxy http://test.test/
http://yayitworked:8080
----------------------------------------------------------------------
proxy.pac:
| dnsResolve("unresolvable.");
| function FindProxyForURL(url, host) { return "PROXY yayitworked:8080"; }
$ proxy http://test.test/
http://yayitworked:8080
----------------------------------------------------------------------
proxy.pac:
| ip = dnsResolve("unresolvable.");
| function FindProxyForURL(url, host) { return "PROXY yayitworked:8080"; }
$ proxy http://test.test/
Segmentation fault
I will probably try the mozjs backend next. This is using the
webkit backend.
Thanks,
Aron
Aron Griffis
Dominique Leuenberger
Unfortunately it segfaults on my proxy.pac. Note my proxy.pac
works fine in firefox, IE and chrome. Without revealing the
content of the proxy.pac, which is private, here is a series of
tests that demonstrates the problem:
I'm aware of a current segfault when using the webkit js parser, when there is invalid javascript being fed 8syntax errors, any error condition). This crash does not happen in the mozjs parser.
This is currently documented in issue #63: http://code.google.com/p/libproxy/issues/detail?id=63
Feel free to add your comments (and patches :) )
Dominique
Aron Griffis
> On Sat, Nov 7, 2009 at 12:59 AM, Aron Griffis <agri...@gmail.com> wrote:
>
> > Unfortunately it segfaults on my proxy.pac. Note my proxy.pac
> > works fine in firefox, IE and chrome. Without revealing the
> > content of the proxy.pac, which is private, here is a series of
> > tests that demonstrates the problem:
> >
>
> I'm aware of a current segfault when using the webkit js parser, when there
> is invalid javascript being fed 8syntax errors, any error condition). This
> crash does not happen in the mozjs parser.
I don't think there's a syntax error in my demonstration. Do you
see one? Here it is for reference:
ip = dnsResolve("unresolvable.");
function FindProxyForURL(url, host) {
return "PROXY localhost:3128";
}
Regarding mozjs, I installed xulrunner-1.9.1-dev on ubuntu karmic
and that allowed ./configure to find the mozjs headers. But
libproxy wouldn't build with it.
Thanks,
Aron
Dominique Leuenberger
I don't think there's a syntax error in my demonstration. Do you
see one? Here it is for reference:
return "PROXY localhost:3128";
ip = dnsResolve("unresolvable.");
function FindProxyForURL(url, host) {
}
Does it still crash if you take the ip=dnsResolve line out (experience showed that it's typically a bad idea to have dns resolving needed in a pac file. very often this has a huge impact on performance than.
Dominique
Aron Griffis
> > I don't think there's a syntax error in my demonstration. Do you
> > see one? Here it is for reference:
> >
> > ip = dnsResolve("unresolvable.");
> > function FindProxyForURL(url, host) {
> > return "PROXY localhost:3128";
> > }
> >
> > That looks simple enough, indeed. I can only assume that dnsResolve might
> cause the problem (I did not use it yet in any script and as such it might
> be less tested.).
>
> Does it still crash if you take the ip=dnsResolve line out
Please take the time to read my messages more carefully.
I already gave a list of scenarios that answers this question.
> (experience
> showed that it's typically a bad idea to have dns resolving needed in a pac
> file. very often this has a huge impact on performance than.
That's exactly why it's outside FindProxyForURL(). This is an
example snippet of a much larger proxy.pac. On a browser, it
happens when proxy.pac loads rather than when the function runs.
With libproxy, it unfortunately will happen every time a command
runs, unless there is a way to keep a persistent pacrunning
going.
Aron
Dominique Leuenberger
Dominique Leuenberger wrote: [Sat Nov 07 2009, 08:39:32AM EST]
> > I don't think there's a syntax error in my demonstration. Do youPlease take the time to read my messages more carefully.
> > see one? Here it is for reference:
> >
> > ip = dnsResolve("unresolvable.");
> > function FindProxyForURL(url, host) {
> > return "PROXY localhost:3128";
> > }
> >
> > That looks simple enough, indeed. I can only assume that dnsResolve might
> cause the problem (I did not use it yet in any script and as such it might
> be less tested.).
>
> Does it still crash if you take the ip=dnsResolve line out
I already gave a list of scenarios that answers this question.
Sorry for that.
I tried to reproduce on my system, but it does not want to crash here.
$> PX_CONFIG_ORDER=config_envvar PX_MODULE_BLACKLIST="pacrunner_*" PX_MODULE_WHITELIST="pacrunner_webkit" http_proxy="pac+file://$(pwd)/proxy.pac" proxy http://test.test
http://yayitworked:8080
$> cat proxy.pac
ip = dnsResolve("unresolvable.");
What version of webkit do you have running? I'm running libwebkit 1.1.15.1.
Aron Griffis
> > > Does it still crash if you take the ip=dnsResolve line out
> >
> > Please take the time to read my messages more carefully.
> > I already gave a list of scenarios that answers this question.
> >
> >
> Sorry for that.
It's okay :-)
> I tried to reproduce on my system, but it does not want to crash here.
Based on the very small changes to the PAC file than can cause it
to crash or not, I think it might be a memory corruption or
reference-after-free kind of problem. I guess since you can't
reproduce it, I'll need to run it under a debugger locally to
find the location of the segfault (and hopefully it still
segfaults in the debugger).
> $> PX_CONFIG_ORDER=config_envvar PX_MODULE_BLACKLIST="pacrunner_*"
> PX_MODULE_WHITELIST="pacrunner_webkit"
> http_proxy="pac+file://$(pwd)/proxy.pac" proxy http://test.test
> http://yayitworked:8080
I was configuring the proxy in gconf rather than environment
variables, but it probably doesn't make a difference. I also
tried with the PAC in an http location, but it segfaulted the
same way. Additionally epiphany segfaults the moment I try to
load a page (presumably the first time libproxy is called).
> What version of webkit do you have running? I'm running libwebkit 1.1.15.1.
1.1.15.2-1 (in ubuntu karmic)
Aron
Nathaniel McCallum
> Based on the very small changes to the PAC file than can cause it
> to crash or not, I think it might be a memory corruption or
> reference-after-free kind of problem. I guess since you can't
> reproduce it, I'll need to run it under a debugger locally to
> find the location of the segfault (and hopefully it still
> segfaults in the debugger).
Just FYI, while I'm all in favor of webkit/jscore, we've had nothing but
trouble with implementing it. It has caused at least 10 crasher bugs
that I know of. This is primarily (I think) due to lack of
documentation on the simple use case we are attempting to implement.
Either that or I am just a dolt. We are welcome to any suggestions to
handle webkit better.
>> $> PX_CONFIG_ORDER=config_envvar PX_MODULE_BLACKLIST="pacrunner_*"
>> PX_MODULE_WHITELIST="pacrunner_webkit"
>> http_proxy="pac+file://$(pwd)/proxy.pac" proxy http://test.test
>> http://yayitworked:8080
>
> I was configuring the proxy in gconf rather than environment
> variables, but it probably doesn't make a difference. I also
> tried with the PAC in an http location, but it segfaulted the
> same way. Additionally epiphany segfaults the moment I try to
> load a page (presumably the first time libproxy is called).
For some reason, almost all the segfaults with webkit have occurred in
dlclose() on the module.
Aron Griffis
>
> On 11/08/2009 11:58 AM, Aron Griffis wrote:
> > Based on the very small changes to the PAC file than can cause it
> > to crash or not, I think it might be a memory corruption or
> > reference-after-free kind of problem. I guess since you can't
> > reproduce it, I'll need to run it under a debugger locally to
> > find the location of the segfault (and hopefully it still
> > segfaults in the debugger).
>
> Just FYI, while I'm all in favor of webkit/jscore, we've had nothing but
> trouble with implementing it. It has caused at least 10 crasher bugs
> that I know of. This is primarily (I think) due to lack of
> documentation on the simple use case we are attempting to implement.
> Either that or I am just a dolt. We are welcome to any suggestions to
> handle webkit better.
Okay, thanks, that matches what I'm seeing (the crashes, not the
dolt ;-)
What about other javascript engines? V8, rhino, kjscmd,
javascript.pm (http://search.cpan.org/dist/JavaScript/). I don't
really know anything about these, I'm just wondering. PAC
processing doesn't need any DOM support, just the core language
plus the PAC sandbox functions.
> >> $> PX_CONFIG_ORDER=config_envvar PX_MODULE_BLACKLIST="pacrunner_*"
> >> PX_MODULE_WHITELIST="pacrunner_webkit"
> >> http_proxy="pac+file://$(pwd)/proxy.pac" proxy http://test.test
> >> http://yayitworked:8080
> >
> > I was configuring the proxy in gconf rather than environment
> > variables, but it probably doesn't make a difference. I also
> > tried with the PAC in an http location, but it segfaulted the
> > same way. Additionally epiphany segfaults the moment I try to
> > load a page (presumably the first time libproxy is called).
>
> For some reason, almost all the segfaults with webkit have occurred in
> dlclose() on the module.
Sounds about right...
I'll try to look into this stuff soon.
Thanks,
Aron
Nathaniel McCallum
>
> Nathaniel McCallum wrote: [Mon Nov 09 2009, 09:28:47AM EST]
>>
>> On 11/08/2009 11:58 AM, Aron Griffis wrote:
>>> Based on the very small changes to the PAC file than can cause it
>>> to crash or not, I think it might be a memory corruption or
>>> reference-after-free kind of problem. I guess since you can't
>>> reproduce it, I'll need to run it under a debugger locally to
>>> find the location of the segfault (and hopefully it still
>>> segfaults in the debugger).
>>
>> Just FYI, while I'm all in favor of webkit/jscore, we've had nothing but
>> trouble with implementing it. It has caused at least 10 crasher bugs
>> that I know of. This is primarily (I think) due to lack of
>> documentation on the simple use case we are attempting to implement.
>> Either that or I am just a dolt. We are welcome to any suggestions to
>> handle webkit better.
>
> Okay, thanks, that matches what I'm seeing (the crashes, not the
> dolt ;-)
>
> What about other javascript engines? V8, rhino, kjscmd,
> javascript.pm (http://search.cpan.org/dist/JavaScript/). I don't
> really know anything about these, I'm just wondering. PAC
> processing doesn't need any DOM support, just the core language
> plus the PAC sandbox functions.
I'm happy to take patches for *any* js engine. I've focused on mozjs
and jscore simply because they are the most widely available. I hope to
support IE's JS at some point in the future.
You are correct, just the sandbox is needed. See:
http://code.google.com/p/libproxy/source/browse/trunk/src/modules/pacutils.js
There are also two sandbox functions that *must* be implemented in C.
See either of the current pacrunners for details.
Nathaniel