-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Segfault in RedisArray test #727
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
Comments
This is another one
Debian jessie, PHP 7.0 |
I can replicate the Will confirm when a fix is up. |
I got my cli stopped working and crashed in this test... |
Quick update for you guys. There are actually a few things that are rather broken in the If anyone cares, it has to do with the "great dereferencing" in the php7 api. Essentially, the api has changed in php7 such that any I should have these fixed over the weekend Cheers |
I'm just planning to switch to 7.0, |
The php7 api has substantial cha 8000 nges in the way one goes about interacting with the zval type (php's internal structure for dealing with dynamically typed variables). Most notably, most everything is dereferenced by one pointer. So, where you once used zval** you typically use zval*, and where you used zval* you now just use a zval struct on the stack. In addition, the api changed in how you return a string. Previously you had the option of whether or not to "duplicate" the memory returned (or in other words, pass ownership of the pointer to PHP or not). Because phpredis sometimes buffers commands to the server (say in the case of a pipeline, or a MULTI/EXEC) transaction, we had several stack violations and/or memory corruption which resulted from keeping track of the address of a stack allocated structure, which was accessed at a later date (sometimes causing segmentation faults, bus errors, etc). Also, there were a few places where this pattern was being used: zval **ptr = emalloc(sizeof(zval*) * count); /* stuff */ ZVAL_STRING(ptr[0], "hello world"); Given that ZVAL_STRING() thinks it's writing to an allocated structure it would cause various random issues (because we were blowing through the data segment and writing into the code section). This commit (so far) fixes all of the segmentation faults and memory errors but there are still leaks (specifically in RedisArray) that need to be solved. Addresses #727
Hey, @szepeviktor and @Jerry-Shaw. My tests are all passing now using the above commit, and I don't see any complaining from valgrind (but I'm still testing). However, there are still quite a few memory leaks with the RedisArray class which I will solve with another commit. I just wanted to get this up so you could test it as well. Cheers! |
Thank you! |
Good, thanks. I'll test it when I have time, little busy these days. |
On a fresh Debian 8.2:
And after fixing nodemap location cluster test says:
|
Solution: |
Ok strange. I don't get any segmentation fault and this is breaking right where it did for me before I updated the code. Are you sure you've recompiled with the updates? It's just odd that it's breaking in the exact same spot. |
In fact, when I run it from the previous commit I see what you're seeing:
With the new code no seg fault, and just one failed test. |
The last test was on a fresh Debian, now it is a fresh install also.
|
Hey thanks for that. I am seeing the same thing myself on that system. How are you building/installing this version of phpredis. Are you using the standard:
I don't want to mess around on your box :) |
Yes, exactly the dame way ss in the readme. You may do anything on this box, it was spun up only for phpredis. +36204242498 On January 26, 2016 8:52:22 PM CET, Michael Grunder notifications@github.com wrote:
|
OK I will see what I can find. This could be a debug vs production build issue. I got a core dump and am taking a peek now. More info soon. Thanks for the help! :) |
That virtual server is deleted. |
Try using Travis with Ubuntu 14, it is free and easy This is what I've done:
https://github.com/phpredis/phpredis/blob/php7/README.markdown#running-the-unit-tests |
@szepeviktor, I have the same warning while compiling the extension. I use the php7 branch.
I just worry if it's safe to use after these errors. |
@starikovs I think these warnings are innocent but should be fixed. |
Ah.. Hi, I still get redisArray Test failed and cli crashed under Win x64. |
There were a few more places mixing emalloc(sizeof(zval*)*N) with emalloc(sizeof(zval)*N causing us to overwrite data in the stack. These didn't appear until the code was built in release mode. Now to build in debug mode to get rid of any leaks. Addresses #727
Ok guys, please try again. More fun times overwriting the stack frame which causes the best kind of errors to debug 😺 These particular errors didn't show up (at least for me) until I built in release mode. There are still some outstanding memory leaks I need to sort so be aware but now all tests pass for me for Redis, RedisArray, and RedisCluster. I will test more running the code through valgrind and then switch back to a debug build so I can track down the leaks. Cheers! |
|
Could we have another dirname() in tests/RedisClusterTest.php? |
OK well that looks much better. The problem with these kinds of bugs is that they are really unpredictable. Sometimes they break, sometimes not so much (and sometimes they change executable code, yay) 😃 I'll look into edit: yes, I'll add |
Hi, all, it is difficult for me to open my laptop when it's near Chinese Spring Festival. A lot of parties with friends and relatives. As for dirname() path in the test's script, I always replace them to dirname(FILE) instead of $_SERVER['PHP_SELF'] before I run it in all the php scripts. OK, I gotta go guys, and will test it later when I have my next chance to open my laptop. |
All tests passed |
How to report this error?
Debian jessie, PHP 7.0
The text was updated successfully, but these errors were encountered: