Bug 701059

Summary: wget / libproxy1 segfault.
Product: [openSUSE] openSUSE 11.4 Reporter: Jon Nelson <jnelson-suse>
Component: OtherAssignee: Dominique Leuenberger <dimstar>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: dimstar
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: Other   
Whiteboard: maint:released:11.4:42607
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Deadline: 2011-09-06   

Description Jon Nelson 2011-06-20 19:37:23 UTC 
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

(gdb) run http://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.4.2.tar.gz
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/wget http://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.4.2.tar.gz
[Thread debugging using libthread_db enabled]

asking libproxy about url 'http://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.4.2.tar.gz'
[New Thread 0x7fffe8a46700 (LWP 629)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff30bd145 in WTF::OSAllocator::reserveAndCommit (bytes=<value optimized out>, usage=<value optimized out>, writable=<value optimized out>, 
    executable=<value optimized out>) at Source/JavaScriptCore/wtf/OSAllocatorPosix.cpp:85
85      Source/JavaScriptCore/wtf/OSAllocatorPosix.cpp: No such file or directory.
        in Source/JavaScriptCore/wtf/OSAllocatorPosix.cpp
(gdb) 
(gdb) 



It's possible that the fix is in the new libproxy (0.4.7).



Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Dominique Leuenberger 2011-06-21 07:07:04 UTC 
Jon,

thank you very much for your bug report.
From the current presented information, it appears you are using either wpad or a proxy auto configuration URL for your proxy settings.

Also, the used javascript parser seems to be the webkit one in your case.

There are several thins I would like to test with you to make sure we're on the right path finding a solution:

First, please install the libproxy-tools package (if you don't have it already).
It contains a 'test' application, called proxy, which queries libproxy based on your configuration, hoping to get the same behavior (it's a very simple test case app).

Then, please execute:
_PX_DEBUG=1 proxy http://www.google.com

=> Does that crash also?

Maybe try:
_PX_DEBUG=1 _MM_DEBUG=1 proxy http://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.4.2.tar.gz
(let's query the same address you used)

I assume this crashes the same way?

It might be worthy to test if only the webkit pacrunner is affected; the mozjs might work just fine:
remove libproxy1-pacrunner-webkit and install libproxy1-pacrunner-mozjs

Perform the same tests again.

Please, if possible, also attach your .pac/wpad.dat
Comment 2 Jon Nelson 2011-06-22 18:23:43 UTC 
(In reply to comment #1)
> Jon,
> 
> thank you very much for your bug report.
> From the current presented information, it appears you are using either wpad or
> a proxy auto configuration URL for your proxy settings.
> 
> Also, the used javascript parser seems to be the webkit one in your case.
> 
> There are several thins I would like to test with you to make sure we're on the
> right path finding a solution:
> 
> First, please install the libproxy-tools package (if you don't have it
> already).
> It contains a 'test' application, called proxy, which queries libproxy based on
> your configuration, hoping to get the same behavior (it's a very simple test
> case app).
> 
> Then, please execute:
> _PX_DEBUG=1 proxy http://www.google.com
> 
> => Does that crash also?

It did not crash when I tried it last night.
It does crash today.

[jnelson~] _PX_DEBUG=1 proxy http://www.google.com
Using config: 20kde_config_extension
Using ignore: 
Config is: pac+http://192.168.1.2/~jnelson/proxy.pac
PAC received!
Using pacrunner: 26webkit_pacrunner_extension
Segmentation fault (core dumped)
[jnelson~] 


> Maybe try:
> _PX_DEBUG=1 _MM_DEBUG=1 proxy
> http://pypi.python.org/packages/source/p/psycopg2/psycopg2-2.4.2.tar.gz
> (let's query the same address you used)
> 
> I assume this crashes the same way?

Yes.

> It might be worthy to test if only the webkit pacrunner is affected; the mozjs
> might work just fine:
> remove libproxy1-pacrunner-webkit and install libproxy1-pacrunner-mozjs

[jnelson~] _PX_DEBUG=1 proxy http://www.google.com
Using config: 20kde_config_extension
Using ignore: 
Config is: pac+http://192.168.1.2/~jnelson/proxy.pac
PAC received!
Unable to find a required pacrunner!
direct://
[jnelson~] rpm -q libproxy1-pacrunner-mozjs
libproxy1-pacrunner-mozjs-0.4.6-3.9.1.x86_64
[jnelson~] 

> 
> Perform the same tests again.
> 
> Please, if possible, also attach your .pac/wpad.dat

[jnelson~] curl -o - http://192.168.1.2/~jnelson/proxy.pac
function FindProxyForURL(url, host)
{
    if (isPlainHostName(host) ||
        dnsDomainIs(host, '.wplc.info') ||
        dnsDomainIs(host, '.contentserve.com') ||
        dnsDomainIs(host, '.local') ||
        dnsDomainIs(host, '.site') ||
        isInNet(host, "192.168.0.0", "255.255.0.0")
        ) {
        return 'DIRECT';
    } else {
        return 'PROXY 192.168.1.2:3128';
    }
}

[jnelson~]
Comment 3 Dominique Leuenberger 2011-06-22 18:58:24 UTC 
(In reply to comment #2)
> > => Does that crash also?
> 
> It did not crash when I tried it last night.
> It does crash today.

Any idea what changed in between? (Was the .pac file available for example?)

> [jnelson~] _PX_DEBUG=1 proxy http://www.google.com
> Using config: 20kde_config_extension
> Using ignore: 
> Config is: pac+http://192.168.1.2/~jnelson/proxy.pac
> PAC received!
> Using pacrunner: 26webkit_pacrunner_extension
> Segmentation fault (core dumped)
> [jnelson~] 

Ok... that is not nice. But at least it's consistently crashing. Which gices us something to work on.

> [jnelson~] _PX_DEBUG=1 proxy http://www.google.com
> Using config: 20kde_config_extension
> Using ignore: 
> Config is: pac+http://192.168.1.2/~jnelson/proxy.pac
> PAC received!
> Unable to find a required pacrunner!
> direct://
> [jnelson~] rpm -q libproxy1-pacrunner-mozjs
> libproxy1-pacrunner-mozjs-0.4.6-3.9.1.x86_64
> [jnelson~] 

Hmm.. mozjs pacrunner seems not to work at all... that's really bad.

Which is a different issue all-together (possibly easier to fix though).
Very likely, the output of "ldd /usr/lib64/libproxy-0.4.7/modules/pacrunner_mozjs.so" will show "libmozjs.so => Not found"

Something that can probably easily be 'worked around' with a symlink.

> [jnelson~] curl -o - http://192.168.1.2/~jnelson/proxy.pac
> function FindProxyForURL(url, host)
> {
>     if (isPlainHostName(host) ||
>         dnsDomainIs(host, '.wplc.info') ||
>         dnsDomainIs(host, '.contentserve.com') ||
>         dnsDomainIs(host, '.local') ||
>         dnsDomainIs(host, '.site') ||
>         isInNet(host, "192.168.0.0", "255.255.0.0")
>         ) {
>         return 'DIRECT';
>     } else {
>         return 'PROXY 192.168.1.2:3128';
>     }
> }

Thanks.. the pac does look simple enough and should not cause too much trouble.
Comment 4 Dominique Leuenberger 2011-06-22 19:02:02 UTC 
(In reply to comment #0)
> It's possible that the fix is in the new libproxy (0.4.7).

Would you be willing to test this if I provide some 0.4.7 packages?
Comment 5 Jon Nelson 2011-06-22 19:35:35 UTC 
(In reply to comment #3)
> (In reply to comment #2)
> > > => Does that crash also?
> > 
> > It did not crash when I tried it last night.
> > It does crash today.
> 
> Any idea what changed in between? (Was the .pac file available for example?)

I believe that simply time and use are sufficient. The .pac file did not change. Last night I tested after logging out and back in again for other reasons.


..

> Hmm.. mozjs pacrunner seems not to work at all... that's really bad.
> 
> Which is a different issue all-together (possibly easier to fix though).
> Very likely, the output of "ldd
> /usr/lib64/libproxy-0.4.7/modules/pacrunner_mozjs.so" will show "libmozjs.so =>
> Not found"

Correct! Why can't it find it?

> Something that can probably easily be 'worked around' with a symlink.

I added the appropriate directory to /etc/ld.so.conf and re-ran ldconfig (as a temporary measure) and re-ran the test app:

Using config: 20kde_config_extension
Using ignore: 
Config is: pac+http://192.168.1.2/~jnelson/proxy.pac
PAC received!
Using pacrunner: 25mozjs_pacrunner_extension
Segmentation fault (core dumped)

...

> Thanks.. the pac does look simple enough and should not cause too much trouble.

regarding:

> Would you be willing to test this if I provide some 0.4.7 packages?


Yes.
Comment 6 Dominique Leuenberger 2011-06-22 20:59:07 UTC 
(In reply to comment #5)
> Correct! Why can't it find it?

Probably an issue from a xulrunner 2.0 update. Xul is in a versioned folder and the update might have moved it to a new folder.
pacrunner_mozjs has an rapth pointing to the folder used during the build

> Using config: 20kde_config_extension
> Using ignore: 
> Config is: pac+http://192.168.1.2/~jnelson/proxy.pac
> PAC received!
> Using pacrunner: 25mozjs_pacrunner_extension
> Segmentation fault (core dumped)

Now THAT is unexpected. It should be a completely different code path. on this pacrunner.

Can you please do:
gdb proxy
run http://www.google.com
(wait for the segfault)
bt full

> > Would you be willing to test this if I provide some 0.4.7 packages?
> 
> Yes.

Packages are building. Once completed I will enable publishing tomorrow.
Comment 7 Jon Nelson 2011-06-22 21:19:21 UTC 
(In reply to comment #6)
> (In reply to comment #5)
> > Correct! Why can't it find it?
> 
> Probably an issue from a xulrunner 2.0 update. Xul is in a versioned folder and
> the update might have moved it to a new folder.
> pacrunner_mozjs has an rapth pointing to the folder used during the build
> 
> > Using config: 20kde_config_extension
> > Using ignore: 
> > Config is: pac+http://192.168.1.2/~jnelson/proxy.pac
> > PAC received!
> > Using pacrunner: 25mozjs_pacrunner_extension
> > Segmentation fault (core dumped)
> 
> Now THAT is unexpected. It should be a completely different code path. on this
> pacrunner.

It's not unexpected if the problem is /before/ the pacrunner stuff is used.

> Can you please do:
> gdb proxy
> run http://www.google.com
> (wait for the segfault)
> bt full

#0  0x00007ffff395453d in getReservedSlot (this=<value optimized out>) at /usr/src/debug/mozilla/js/src/jsobjinlines.h:248
#1  extractFrom (this=<value optimized out>) at /usr/src/debug/mozilla/js/src/jsregexpinlines.h:594
#2  JSContext::regExpStatics (this=<value optimized out>) at /usr/src/debug/mozilla/js/src/jscntxtinlines.h:115
#3  0x00007ffff399d063 in str_search (cx=0x6bd500, argc=1, vp=0x7ffff27cd120) at /usr/src/debug/mozilla/js/src/jsstr.cpp:1910
#4  0x00007ffff38ec019 in CallJSNative (cx=<value optimized out>, entryFrame=0x7ffff27cd058, inlineCallCount=1, interpMode=JSINTERP_NORMAL)
    at /usr/src/debug/mozilla/js/src/jscntxtinlines.h:701
#5  js::Interpret (cx=<value optimized out>, entryFrame=0x7ffff27cd058, inlineCallCount=1, interpMode=JSINTERP_NORMAL)
    at /usr/src/debug/mozilla/js/src/jsinterp.cpp:4799
#6  0x00007ffff38f8965 in js::RunScript (cx=0x6bd500, script=0x72c230, fp=0x7ffff27cd058) at /usr/src/debug/mozilla/js/src/jsinterp.cpp:653
#7  0x00007ffff38fa832 in js::Invoke (cx=0x6bd500, argsRef=<value optimized out>, flags=<value optimized out>)
    at /usr/src/debug/mozilla/js/src/jsinterp.cpp:740
#8  0x00007ffff38fad1b in js::ExternalInvoke (cx=0x6bd500, thisv=..., fval=..., argc=2, argv=0x7ffffffe45a0, rval=0x7ffffffe45b8)
    at /usr/src/debug/mozilla/js/src/jsinterp.cpp:863
#9  0x00007ffff3869904 in JS_CallFunctionName (cx=0x6bd500, obj=0x7ffff2603048, name=<value optimized out>, argc=2, argv=0x7ffffffe45a0, rval=0x7ffffffe45b8)
    at /usr/src/debug/mozilla/js/src/jsapi.cpp:5159
#10 0x00007ffff3da5438 in mozjs_pacrunner::run (this=0x62c3f0, url_=<value optimized out>)
    at /usr/src/debug/libproxy-0.4.6/libproxy/modules/pacrunner_mozjs.cpp:165
#11 0x00007ffff7bc986e in libproxy::proxy_factory::_get_proxies (this=0x603010, realurl=0x60b770, response=...)
    at /usr/src/debug/libproxy-0.4.6/libproxy/proxy.cpp:372
#12 0x00007ffff7bcad6e in libproxy::proxy_factory::get_proxies (this=0x603010, url_=...) at /usr/src/debug/libproxy-0.4.6/libproxy/proxy.cpp:194
#13 0x00007ffff7bcaf0c in px_proxy_factory_get_proxies (self=0x603010, url=<value optimized out>) at /usr/src/debug/libproxy-0.4.6/libproxy/proxy.cpp:420
#14 0x0000000000400d2c in main ()
(gdb) 



(gdb) frame 11
#11 0x00007ffff7bc986e in libproxy::proxy_factory::_get_proxies (this=0x603010, realurl=0x60b770, response=...)
    at /usr/src/debug/libproxy-0.4.6/libproxy/proxy.cpp:372
372     /usr/src/debug/libproxy-0.4.6/libproxy/proxy.cpp: No such file or directory.
        in /usr/src/debug/libproxy-0.4.6/libproxy/proxy.cpp
(gdb) print realurl
$1 = (libproxy::url *) 0x60b770
(gdb) print *realurl
$2 = {m_orig = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = 
    {<No data fields>}, <No data fields>}, _M_p = 0x62a1e8 "http://www.google.com"}}, m_scheme = {static npos = 18446744073709551615, _M_dataplus = 
    {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x626ab8 "http"}}, m_user = {static npos = 
    18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 
    0x7ffff7400278 ""}}, m_pass = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = 
    {<No data fields>}, <No data fields>}, _M_p = 0x7ffff7400278 ""}}, m_host = {static npos = 18446744073709551615, _M_dataplus = {<std::allocator<char>> = 
    {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x6271b8 "www.google.com"}}, m_port = 80, m_path = {static npos = 
    18446744073709551615, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 
    0x7ffff7400278 ""}}, m_ips = 0x0}
(gdb)
Comment 8 Jon Nelson 2011-07-11 01:20:16 UTC 
> Packages are building. Once completed I will enable publishing tomorrow.

have packages built properly?
Comment 9 Dominique Leuenberger 2011-07-18 21:55:53 UTC 
Sorry for the delay!
Packages are built and can be found at
http://download.opensuse.org/repositories/home:/dimstar:/bnc701059/standard/

Please let me know if those resolve your issue.
Comment 10 Jon Nelson 2011-07-21 17:01:10 UTC 
I *think* this has resolved the issue.
As before, sometimes the segfaulting didn't show up right away, but so far so good.
If it comes back, I'll be sure to let you know.

Thanks!
Comment 11 Jon Nelson 2011-08-04 16:11:18 UTC 
I haven't had any more problems with libproxy since the update.
When can the fix go into openSUSE 11.4 (and make sure it gets into 12.whatever!)?
Comment 12 Dominique Leuenberger 2011-08-04 16:24:07 UTC 
maintenance: Is an update to the 0.4.7 release permitted? It's API and ABI compatible to 0.4.6, as shipped in 11.4)
Comment 13 Christian Dengler 2011-08-04 16:31:59 UTC 
Yes, it is okay.

+1
Comment 14 Jon Nelson 2011-08-04 16:53:47 UTC 
I should note that the packages provided (4.7) have debugging enabled, so one always gets:

asking libproxy about url ....
libproxy suggest to use ...
and so on.
Comment 15 Dominique Leuenberger 2011-08-04 18:05:26 UTC 
(In reply to comment #14)
> I should note that the packages provided (4.7) have debugging enabled, so one
> always gets:
> 
> asking libproxy about url ....
> libproxy suggest to use ...
> and so on.

This output ia by wget, not by libproxy.
Comment 16 Marcus Meissner 2011-08-08 09:20:17 UTC 
i reviewed the diff, seems binary compatible ... +1
Comment 17 Dominique Leuenberger 2011-08-08 09:49:33 UTC 
Just see another libproxy bug, will co-ordinate a fix for them together
See bug 679322.
Comment 18 Marcus Meissner 2011-08-08 09:51:05 UTC 
please also tell upstream that they mistyped google.com in one of the testcases (they used googe.com)
Comment 19 Dominique Leuenberger 2011-08-08 09:58:26 UTC 
(In reply to comment #18)
> please also tell upstream that they mistyped google.com in one of the testcases
> (they used googe.com)
Thanks.. that typo has been fixed in upstream svn.
Comment 20 Swamp Workflow Management 2011-08-09 13:44:20 UTC 
The SWAMPID for this issue is 42563.
This issue was rated as low.
Please submit fixed packages until 2011-09-06.
Also create a patchinfo file using this link:
https://swamp.suse.de/webswamp/wf/42563
Comment 21 Christian Dengler 2011-08-09 13:49:38 UTC 
update started.
Comment 22 Christian Dengler 2011-08-16 14:38:06 UTC 
Dominique,
can you submit the fixed sources?
Comment 23 Benjamin Brunner 2011-08-25 13:14:19 UTC 
Accepted for update.
Comment 24 Swamp Workflow Management 2011-08-25 13:18:03 UTC 
Update released for: libproxy, libproxy-debugsource, libproxy-devel, libproxy-plugins, libproxy-plugins-debugsource, libproxy-sharp, libproxy-tools, libproxy-tools-debuginfo, libproxy1, libproxy1-32bit, libproxy1-config-gnome, libproxy1-config-gnome-32bit, libproxy1-config-gnome-debuginfo, libproxy1-config-gnome-debuginfo-32bit, libproxy1-config-kde4, libproxy1-config-kde4-debuginfo, libproxy1-debuginfo, libproxy1-debuginfo-32bit, libproxy1-networkmanager, libproxy1-networkmanager-32bit, libproxy1-networkmanager-debuginfo, libproxy1-networkmanager-debuginfo-32bit, libproxy1-pacrunner-mozjs, libproxy1-pacrunner-mozjs-32bit, libproxy1-pacrunner-mozjs-debuginfo, libproxy1-pacrunner-mozjs-debuginfo-32bit, libproxy1-pacrunner-webkit, libproxy1-pacrunner-webkit-32bit, libproxy1-pacrunner-webkit-debuginfo, libproxy1-pacrunner-webkit-debuginfo-32bit, perl-Net-Libproxy, perl-Net-Libproxy-debuginfo, python-libproxy
Products:
openSUSE 11.4 (debug, i586, x86_64)