A "problem" caused by GCC Optimization"

Author: Laruence () address of this article: www.laruence.com201406262955.html reprinted. Please note that the source was originally posted on long Weibo. However, in view of this, if you haven't updated your blog for a long time, please refer to it, we spent nearly two hours watching the white-hot job, so we don't have to vomit: everything is going to start from around five o'clock P.M. today, debugging an extension.

Author: Laruence () address of this article: http://www.laruence.com/2014/06/26/2955.html reprint please indicate the source is originally sent in long microblogging, but, in view of, for a long time did not update the blog on the turn, gather the number of it, we spent nearly two hours watching the white-hot job, so we don't have to vomit: everything is going to start from around five o'clock P.M. today, debugging an extension.

• Author: Laruence ()
• Address: http://www.laruence.com/2014/06/26/2955.html
• Reprinted please indicate the source

It was originally posted on long Weibo, but since it has not been updated for a long time ...... Let's turn it over. Let's get together the number.

I have been busy for nearly two hours, so I don't want to vomit:

Everything is going to start from around five o'clock P.M. today, debugging an extension, using valgrind (valgrind-3.8.1) for routine checks, unfortunately valgrind reports invalid read:

When db attach is enabled, the following errors are reported:

Because in php ng (PHP New Generation), a New string structure is used to save the string, that is, zend_string:

After troubleshooting for half a day, I confirmed that the op was properly initialized. What is the problem?

I suddenly saw op as a string with a length of 1 "0" and suddenly remembered that we made a "fine" optimization before, because for the above struct, in a 64-bit system, sizeof it, due to padding, will actually get a size larger than 8 + 8 + 4 + 1 (21) (8 + 8 + 8 = 24 ).

So we will not use the general practice:

str = malloc(sizeof(str) + len + 1)

To apply for memory for a string with the length of len. Instead, the following code is used:

str = malloc ((int)((str*)0)->val) + len + 1)

To apply for memory for a string, so for "0", we actually apply to allocate 22 bytes of memory.

But what's the problem? So let's go to db attach again, and let's take a look at the reason for disassmble:

Well, the problem lies in the f3b5 line. GCC reads a word size data at the position 0 × 10 (% rdx). % rdx is the zend_string op pointer at this time, the offset of 0x10 is str-> len. it turns out that the GCC optimization is clever.

if (str->len == 1 && str->val[0] == '0')

Optimized to a command that is compared with a data 0x3000000001 ....

As mentioned above, because this str only has 22 bytes, when trying to read 8 bytes from the 16 offset, we actually read three more bytes in the str structure ...... So it's invalid read.

The problem is clear. A harmless report (and 0 xffffffffff) is caused by the clever Optimization of GCC )............ So, I am busy .... (Of course, it is best to fix it. The solution I plan to fix now is to allocate a minimum of 24 bytes ).

Comments

• , Goghcrow writes: Gao dashang
• , Kalcaddle writes: KodExplorer, an open-source web file management software for php, is recommended. It can replace ftp to back up and decompress websites, and drag and drop folders for uploading; online Editor webIDE (more than 60 code highlighting and Automatic completion): http://www.kalcaddle.com/download.htmlsupports open source!
• , T. k. writes. I think this problem may be avoided if you modify the padding parameter of gcc based on the existing code.
• , 23213213 writes: 34324324
• , Ccg writes: _ zend_string struct specifies whether the byte alignment is 1 # pragma pack (1) can solve the problem
• , Writes: Good blog, the content is exactly what I need.

Copyright©2010 All Rights Reserved. this Feed is for personal use only. reposted or commercial applications that are not specified are prohibited. if the application is illegal, all legal consequences shall be borne by you. if you have any questions, you can send an email to my at laruence.com. (Digital Fingerprint: 73540ba0a1738d7d07d4b6038d5615e2)