-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Digest crashes with md5 #2
Comments
Could you try to run the test cases? This is mighty strange, as the vmod-code is as close to algorithm agnostic as it gets. |
Hi, On tor, des 20, 2012 at 11:29:37am -0800, Kristian Lyngstøl wrote:
Attached test case runs. Bye Anders.
**** v1 0.9 vsl| 7 SessionOpen c 127.0.0.1 50994 127.0.0.1:0
top TEST tests/test01.vtc FAILED (1.936) exit=1**** top 0.0 macro def varnishd=/usr/ports/www/varnish/work/varnish-3.0.3/bin/varnishd/varnishd
**** v1 1.0 vsl| 7 SessionOpen c 127.0.0.1 59311 127.0.0.1:0
top TEST tests/test_hash.vtc FAILED (2.062) exit=1top TEST tests/test_nullstring.vtc passed (1.111) |
Hmm, this looks like something I'll have to look into in early January. Thanks for the test output, it suggests some nefarious stuff... Hopefully it'll be easy to spot. |
Hi. This has been laying stale after Kristian left the company. Sorry about that. Had a look at this now, and on my debian wheezy system I'm not able to reproduce it. libmhash version is: I set up a travis-ci job for it as well, and it looks to pass nicely as well: https://travis-ci.org/lkarsten/libvmod-digest My best guess here is that either is some other vmod/inline-C doing things it shouldn't, or libmhash on freebsd is different. I ran 40kreq/s against digest.hash_md5() (in vcl_recv, setting req.http, not resp.http..) for 10 minutes now, and I haven't seen any crashes. Are you still able to reproduce this? |
Nothing heard, closing this for now. |
Sorry for the late response. But this has now become a serious issue for us. While doing some digest.hash_md5, Varnish constantly crashes: Feb 10 11:34:10 cachetest1 kernel: pid 76808 (varnishd), uid 65534: exited on signal 11 If I (gdb) bt Running the test cases, they fail: [root@cachetest1 ~/libvmod-digest]# gmake check
**** v1 1.0 vsl| 7 SessionOpen c 127.0.0.1 25274 127.0.0.1:0
top TEST tests/test01.vtc FAILED (2.010) exit=1gmake[1]: *** [tests/test01.vtc] Error 2 |
Turns out there is a naming conflict between functions in libmd (which Varnish on freebsd/ports links against for some reason) and functions in libmhash. Upon loading vmod-digest various functions (MD5Init, MD5Final, MD5Update, ...) get resolved from /lib/libmd.so and not libmhash, with disastrous results. :-/ A workaround to make it prefer libmhash is to set LD_PRELOAD prior to launching varnishd. The following command makes all the tests pass for me: $ gmake check LD_PRELOAD=/usr/local/lib/libmhash.so |
problems when using libmhash and/or digest vmod. More info: varnish/libvmod-digest#2
problems when using libmhash and/or digest vmod. More info: varnish/libvmod-digest#2 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@345093 35697150-7ecd-e111-bb59-0022644237b5
I think this might still be an issue? am using a macports install of varnish-3.0.4, and a build of this off of the 3.0 branch. In addition, I had to build from source the mhash-0.9.9.9 library. running "gmake check LD_PRELOAD=/usr/local/lib/libmhash.so" gives me the following test results:
any thoughts on how to get varnish to stop dying with md5 is called? |
I'll reopen this issue. |
Please try a more recent version, if you can still reproduce it feel free to reopen. |
When I use digest.hash_md5 with any value Varnish crashes:
(gdb) bt
#0 0x0000000801caa5d7 in strlen () from /lib/libc.so.7
#1 0x0000000000440f0f in VRT_StringList (
#2 0x00000000004410a9 in VRT_String (ws=0x8083cd080,
#3 0x0000000000441431 in VRT_SetHdr (sp=0x8083cd008, where=HDR_REQ,
#4 0x0000000807502338 in ?? ()
#5 0x00000008083cd398 in ?? ()
#6 0x000000000068272e in H_Expect ()
#7 0x0000000000000800 in ?? ()
#8 0x00007fffedb5a4d0 in ?? ()
#9 0x0000000802008400 in ?? ()
#10 0x000000000043faf7 in VCL_recv_method (sp=0x0) at vcl_returns.h:23
Previous frame inner to this frame (corrupt stack?)
(gdb) quit
My setup:
The text was updated successfully, but these errors were encountered: