Thread: BUG #6460: routine my_log2 use incorrect data type ?
The following bug has been logged on the website: Bug reference: 6460 Logged by: lxzou Email address: zoulx1982@163.com PostgreSQL version: 9.1.2 Operating system: Windows Server 2008 64 bit Description:=20=20=20=20=20=20=20=20 Hi, I startup postgres in win server 2008 64-bit with shared_buffers=3D1073741819, but find it doesn't work. I debug the postgres use vs2008, and find it enter an Infinite loop in my_log2. when the parameter num is between (2^30) + 1 and (2^31) -1, it will be an Infinite loop. because long in win 64 is 4 bytes, so (2^30) << 1 is 2^31, i.e. -2^31. move left again it will be zero. size_t in win64 is 8 bytes=EF=BC=8Cso add_size and mul_size can't check ove= rflow, but in win32 it can do that. So, whether we should use Size instead of long ? Best wishes
zoulx1982@163.com writes:
> I startup postgres in win server 2008 64-bit with
> shared_buffers=1073741819, but find it doesn't work.
Well, that's hardly the fault of my_log2. What you should have gotten
is
FATAL: requested shared memory size overflows size_t
and I do get that when I try that value. Apparently the overflow check
in mul_size() is broken in your build. Did you build it yourself, and
if so with which compiler and what compilation options? If you didn't
build it yourself, where did you get it from?
> size_t in win64 is 8 bytes, so add_size and mul_size can't check overflow,
Sure they can. Or at least if they can't, it's not because of size_t
being 8 bytes. That code works fine on every other 64-bit platform.
regards, tom lane
eWVzLCBJICBidWlsZCBpdCBieSBteXNlbGYsIGFuZCB0aGUgdmVyc2lvbiBp cyA5LjEuMiwgZm9sbG93aW5nIGlzIG15IGJ1aWxkIHByb2Nlc3MuCjEuICBp biBWaXN1YWwgU3R1ZGlvIDIwMDggeDY0IGNtZCwgZXhlYyAgInNldCBDT05G SUc9REVCVUciCjIuICBleGVjICJidWlsZCIgLCBhbmQgaSBzZWUgIkRldGVj dGVkIGhhcmR3YXJlIHBsYXRmb3JtOiB4NjQiCjMuIGV4ZWMgInBlcmwgaW5z dGFsbC5wbCBpbnN0YWxsMiBEZWJ1ZyIKNC4gY2QgKioqKi9pbnN0YWxsMgo1 LiBpbml0ZGIgYSBkYXRhIGRpciwgImluaXRkYi5leGUgLUF0cnVzdCAtVVNZ U1RFTSAtLW5vLWxvY2FsZSAtRCAuLi9kYXRhIgo2LiBzdGFydHVwIHBvc3Rn cmVzICIicG9zdGdyZXMiIC1EICIuLi9kYXRhIiAtYyBzaGFyZWRfYnVmZmVy cz0xMDczNzQxODE5IgogCmFib3ZlIGlzIG15IGJ1aWxkIHByb2Nlc3MsIGFu ZCB3aGV0aGVyIG9uZSBvZiB0aGVzZSBzdGVwcyBpbmNvcnJlY3QgPwogCmhl cmUgaXMgc3RhY2sgaW5mbwogcG9zdGdyZXMuZXhlIW15X2xvZzIobG9uZyBu dW09MTA3Mzc0MTgzNSkgINDQMTM5NyArIDB4MWUg19a92iBDCiAgcG9zdGdy ZXMuZXhlIWhhc2hfZXN0aW1hdGVfc2l6ZShsb25nIG51bV9lbnRyaWVzPTEw NzM3NDE4MzUsIHVuc2lnbmVkIF9faW50NjQgZW50cnlzaXplPTI0KSAg0NA2 MjYgKyAweDkg19a92iBDCiAgcG9zdGdyZXMuZXhlIUJ1ZlRhYmxlU2htZW1T aXplKGludCBzaXplPTEwNzM3NDE4MzUpICDQ0DQ2IEMKICBwb3N0Z3Jlcy5l eGUhU3RyYXRlZ3lTaG1lbVNpemUoKSAg0NAyODcgKyAweGUg19a92iBDCiAg cG9zdGdyZXMuZXhlIUJ1ZmZlclNobWVtU2l6ZSgpICDQ0DE3NSArIDB4NSDX 1r3aIEMKICBwb3N0Z3Jlcy5leGUhQ3JlYXRlU2hhcmVkTWVtb3J5QW5kU2Vt YXBob3JlcyhjaGFyIG1ha2VQcml2YXRlPTAsIGludCBwb3J0PTU0MzIpICDQ 0DEwNyArIDB4NSDX1r3aIEMKICBwb3N0Z3Jlcy5leGUhcmVzZXRfc2hhcmVk KGludCBwb3J0PTU0MzIpICDQ0DIxMjIgQwogIHBvc3RncmVzLmV4ZSFQb3N0 bWFzdGVyTWFpbihpbnQgYXJnYz01LCBjaGFyICogKiBhcmd2PTB4MDAwMDAw MDAwMDg3MzU5MCkgINDQOTcxIEMKICBwb3N0Z3Jlcy5leGUhbWFpbihpbnQg YXJnYz01LCBjaGFyICogKiBhcmd2PTB4MDAwMDAwMDAwMDg3MzU5MCkgINDQ MTk5ICsgMHhlINfWvdogQwoKIApiZXN0IHdpc2hlcwoKQXQgMjAxMi0wMi0x OCAwNjoyNzowNCwiVG9tIExhbmUiIDx0Z2xAc3NzLnBnaC5wYS51cz4gd3Jv dGU6Cj56b3VseDE5ODJAMTYzLmNvbSB3cml0ZXM6Cj4+ICBJIHN0YXJ0dXAg cG9zdGdyZXMgaW4gd2luIHNlcnZlciAyMDA4IDY0LWJpdCB3aXRoCj4+IHNo YXJlZF9idWZmZXJzPTEwNzM3NDE4MTksIGJ1dCBmaW5kIGl0IGRvZXNuJ3Qg d29yay4KPgo+V2VsbCwgdGhhdCdzIGhhcmRseSB0aGUgZmF1bHQgb2YgbXlf bG9nMi4gIFdoYXQgeW91IHNob3VsZCBoYXZlIGdvdHRlbgo+aXMKPgo+RkFU QUw6ICByZXF1ZXN0ZWQgc2hhcmVkIG1lbW9yeSBzaXplIG92ZXJmbG93cyBz aXplX3QKPgo+YW5kIEkgZG8gZ2V0IHRoYXQgd2hlbiBJIHRyeSB0aGF0IHZh bHVlLiAgQXBwYXJlbnRseSB0aGUgb3ZlcmZsb3cgY2hlY2sKPmluIG11bF9z aXplKCkgaXMgYnJva2VuIGluIHlvdXIgYnVpbGQuICAgRGlkIHlvdSBidWls ZCBpdCB5b3Vyc2VsZiwgYW5kCj5pZiBzbyB3aXRoIHdoaWNoIGNvbXBpbGVy IGFuZCB3aGF0IGNvbXBpbGF0aW9uIG9wdGlvbnM/ICBJZiB5b3UgZGlkbid0 Cj5idWlsZCBpdCB5b3Vyc2VsZiwgd2hlcmUgZGlkIHlvdSBnZXQgaXQgZnJv bT8KPgo+PiBzaXplX3QgaW4gd2luNjQgaXMgOCBieXRlcywgc28gYWRkX3Np emUgYW5kIG11bF9zaXplIGNhbid0IGNoZWNrIG92ZXJmbG93LAo+Cj5TdXJl IHRoZXkgY2FuLiAgT3IgYXQgbGVhc3QgaWYgdGhleSBjYW4ndCwgaXQncyBu b3QgYmVjYXVzZSBvZiBzaXplX3QKPmJlaW5nIDggYnl0ZXMuICBUaGF0IGNv ZGUgd29ya3MgZmluZSBvbiBldmVyeSBvdGhlciA2NC1iaXQgcGxhdGZvcm0u Cj4KPiByZWdhcmRzLCB0b20gbGFuZQoKCgo=
yes, I build it by myself, and the version is 9.1.2, following is my build process.
1. in Visual Studio 2008 x64 cmd, exec "set CONFIG=DEBUG"
1. in Visual Studio 2008 x64 cmd, exec "set CONFIG=DEBUG"
2. exec "build" , and i see "Detected hardware platform: x64"
3. exec "perl install.pl install2 Debug"
4. cd ****/install2
5. initdb a data dir, "initdb.exe -Atrust -USYSTEM --no-locale -D ../data"
6. startup postgres ""postgres" -D "../data" -c shared_buffers=1073741819"
above is my build process, and whether one of these steps incorrect ?
here is stack info
postgres.exe!my_log2(long num=1073741835) 行1397 + 0x1e 字节 C
postgres.exe!hash_estimate_size(long num_entries=1073741835, unsigned __int64 entrysize=24) 行626 + 0x9 字节 C
postgres.exe!BufTableShmemSize(int size=1073741835) 行46 C
postgres.exe!StrategyShmemSize() 行287 + 0xe 字节 C
postgres.exe!BufferShmemSize() 行175 + 0x5 字节 C
postgres.exe!CreateSharedMemoryAndSemaphores(char makePrivate=0, int port=5432) 行107 + 0x5 字节 C
postgres.exe!reset_shared(int port=5432) 行2122 C
postgres.exe!PostmasterMain(int argc=5, char * * argv=0x0000000000873590) 行971 C
postgres.exe!main(int argc=5, char * * argv=0x0000000000873590) 行199 + 0xe 字节 C
postgres.exe!hash_estimate_size(long num_entries=1073741835, unsigned __int64 entrysize=24) 行626 + 0x9 字节 C
postgres.exe!BufTableShmemSize(int size=1073741835) 行46 C
postgres.exe!StrategyShmemSize() 行287 + 0xe 字节 C
postgres.exe!BufferShmemSize() 行175 + 0x5 字节 C
postgres.exe!CreateSharedMemoryAndSemaphores(char makePrivate=0, int port=5432) 行107 + 0x5 字节 C
postgres.exe!reset_shared(int port=5432) 行2122 C
postgres.exe!PostmasterMain(int argc=5, char * * argv=0x0000000000873590) 行971 C
postgres.exe!main(int argc=5, char * * argv=0x0000000000873590) 行199 + 0xe 字节 C
best wishes
At 2012-02-18 06:27:04,"Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>zoulx1982@163.com writes:
>> I startup postgres in win server 2008 64-bit with
>> shared_buffers=1073741819, but find it doesn't work.
>
>Well, that's hardly the fault of my_log2. What you should have gotten
>is
>
>FATAL: requested shared memory size overflows size_t
>
>and I do get that when I try that value. Apparently the overflow check
>in mul_size() is broken in your build. Did you build it yourself, and
>if so with which compiler and what compilation options? If you didn't
>build it yourself, where did you get it from?
>
>> size_t in win64 is 8 bytes, so add_size and mul_size can't check overflow,
>
>Sure they can. Or at least if they can't, it's not because of size_t
>being 8 bytes. That code works fine on every other 64-bit platform.
>
> regards, tom lane