Floating Point Exception #570

superdav42 · 2012-08-29T08:29:19Z

Working with number larger than 65,535 is failing with a floating point exception with hphp.
This simple program compiles fine but does not run:

sgolemon · 2012-08-30T23:11:02Z

Not seeing that happen here, and in fact we just recently did a test install of Wordpress and it worked right out of the box. (Blog post on this coming, in fact)

Can you provide further context?
What distro are you running? What packages do you have installed, etc...

superdav42 · 2012-09-01T01:53:59Z

I'm using Debian testing. Gcc 4.6.3 since 4.7 doesn't work. Cmake version 2.8.9-rc1. Not sure what else would be helpful.

Here's a backtrace from gdb running the compiled program:
Program received signal SIGFPE, Arithmetic exception.
#0 0x000000000077068f in std::tr1::_Hashtable<long long, std::pair<long long const, HPHP::StringData const*>, std::allocator<std::pair<long long const, HPHP::StringData const*> >, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, std::equal_to, HPHP::int64_hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>::find(long long const&) [clone .isra.115] clone .constprop.183
#1 0x00000000006ef5b3 in HPHP::String::PreConvertInteger(long long) ()
#2 0x00000000006f55e0 in _GLOBAL__sub_I_cpputil.cpp ()
#3 0x0000000000ef447d in __libc_csu_init ()
#4 0x00007ffff17d6e40 in __libc_start_main ()
from /lib/x86_64-linux-gnu/libc.so.6
#5 0x0000000000713349 in _start ()

Not terribly helpful to me. Is there some debugging switches I could use to enable debug symbols with hphp?

d3xt3r01 · 2012-09-01T10:11:43Z

d3xt3r01 www # cat t.php

thedjnK · 2012-09-01T10:16:45Z

Seems to be similiar to #552
Yes 5 minutes is normal, takes approximately 7 and a half minutes here.

d3xt3r01 · 2012-09-01T10:18:34Z

Ok, great, now we only need to get a fix :|

WhiteRabbit-Code · 2012-09-04T08:38:07Z

I have the same problem here, compiling works without errors, but on execution I get an floating-point exception.
Output of gdb is:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGFPE, Arithmetic exception.
0x0000000000cd3291 in std::tr1::__detail::_Mod_range_hashing::operator() (this=0x2357483, __num=3801622402550600085,
__den=0) at /usr/include/c++/4.6/tr1/hashtable_policy.h:369
369 { return __num % __den; }

System is: Linux probook 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

A fix for this would be great!

thedjnK · 2012-09-07T16:31:32Z

Getting same error on a big-ish project that works fine in the pre-HHVM version of HPHP, HHVM works fine but trying to use the new HPHP just won't work.

Output of compilation:
export CMAKE_PREFIX_PATH='/hiphop'
export HPHP_HOME='/hiphop/facebook-hiphop-php-7839972'
export HPHP_LIB='/hiphop/facebook-hiphop-php-7839972/bin'
export USE_HHVM=1
cd /html/
$HPHP_HOME/src/hphp/hphp --input-list=file.list -k 1 --log=3 --include-path="." --force=1 --cluster-count=50 --target=cpp --format=exe
running hphp...
creating temporary directory /tmp/hphp_1ltKCA ...
parsing inputs...
parsing inputs took 0'00" (112 ms) wall time
pre-optimizing...
pre-optimizing took 0'00" (287 ms) wall time
analyze includes...
analyze includes took 0'00" (0 ms) wall time
inferring types...
inferring types took 0'00" (135 ms) wall time
post-optimizing...
post-optimizing took 0'00" (248 ms) wall time
creating CPP files...
creating CPP files took 0'00" (260 ms) wall time
compiling and linking CPP files...
compiling and linking CPP files took 4'12" (252644 ms) wall time
all files saved in /tmp/hphp_1ltKCA ...
running hphp took 4'13" (253910 ms) wall time

And here is what happens when I try to do anything with the compiled program;
/tmp/hphp_1ltKCA/program
Floating point exception

And here's the output of GDB:
Reading symbols from /tmp/hphp_1ltKCA/program...done.
(gdb) run
Starting program: /tmp/hphp_1ltKCA/program
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGFPE, Arithmetic exception.
0x0000000000c0277f in std::tr1::_Hashtable<long long, std::pair<long long const, HPHP::StringData const*>, std::allocator<std::pair<long long const, HPHP::StringData const*> >, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, std::equal_to, HPHP::int64_hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>::find(long long const&) [clone .isra.117] clone .constprop.193

davidpenn · 2012-09-07T17:56:47Z

Having the same issuing trying to setcookie() with time() + 2678400. Even tried just setcookie("name", "value", 1378564901) without any math and still crashes with the same error.

Program received signal SIGFPE, Arithmetic exception.
0x0000000000b8fd21 in std::tr1::__detail::_Mod_range_hashing::operator() (this=0x2181ca3, __num=3174807277286488931, __den=0) at /usr/include/c++/4.6/tr1/hashtable_policy.h:369
369 { return __num % __den; }
(gdb) bt
#0 0x0000000000b8fd21 in std::tr1::__detail::_Mod_range_hashing::operator() (this=0x2181ca3, __num=3174807277286488931, __den=0) at /usr/include/c++/4.6/tr1/hashtable_policy.h:369
#1 0x0000000000ba98d9 in std::tr1::__detail::_Hash_code_base<long long, std::pair<long long const, HPHP::StringData const*>, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, std::equal_to, HPHP::int64_hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, false>::_M_bucket_index (this=0x2181ca0,
__c=3174807277286488931, __n=0) at /usr/include/c++/4.6/tr1/hashtable_policy.h:677
#2 0x0000000000ba9729 in std::tr1::_Hashtable<long long, std::pair<long long const, HPHP::StringData const*>, std::allocator<std::pair<long long const, HPHP::StringData const*> >, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, std::equal_to, HPHP::int64_hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>::find (this=0x2181ca0, __k=@0x7fffffffe458: 2678400) at /usr/include/c++/4.6/tr1/hashtable.h:697
#3 0x0000000000bfcf8e in HPHP::String::PreConvertInteger (n=2678400) at /usr/src/facebook/hiphop-php/src/runtime/base/type_string.cpp:68

(gdb) break HPHP::String::PreConvertInteger
Breakpoint 1 at 0xbfcf7d: file /usr/src/facebook/hiphop-php/src/runtime/base/type_string.cpp, line 68.

(gdb) run
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, HPHP::String::PreConvertInteger (n=2678400) at /usr/src/facebook/hiphop-php/src/runtime/base/type_string.cpp:68
68 integer_string_data_map.find(n);

(gdb) list
63 return sd;
64 }
65
66 void String::PreConvertInteger(int64 n) {
67 IntegerStringDataMap::const_iterator it =
68 integer_string_data_map.find(n);
69 if (it != integer_string_data_map.end()) return;
70 integer_string_data_map[n] = convert_integer_helper(n, NULL);
71 }
72

(gdb) print integer_string_data_map
$1 = {<std::tr1::unordered_map<long long, HPHP::StringData const*, HPHP::int64_hash, std::equal_to, std::allocator<std::pair<long long const, HPHP::StringData const*> > >> = {<std::tr1::__unordered_map<long long, HPHP::StringData const*, HPHP::int64_hash, std::equal_to, std::allocator<std::pair<long long const, HPHP::StringData const*> >, false>> = {<std::tr1::_Hashtable<long long, std::pair<long long const, HPHP::StringData const*>, std::allocator<std::pair<long long const, HPHP::StringData const*> >, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, std::equal_to, HPHP::int64_hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>> = {<std::tr1::__detail::_Rehash_base<std::tr1::__detail::_Prime_rehash_policy, std::tr1::_Hashtable<long long, std::pair<long long const, HPHP::StringData const*>, std::allocator<std::pair<long long const, HPHP::StringData const*> >, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, std::equal_to, HPHP::int64_hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true> >> = {}, <std::tr1::__detail::_Hash_code_base<long long, std::pair<long long const, HPHP::StringData const*>, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, std::equal_to, HPHP::int64_hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, false>> = {
_M_extract = {<std::unary_function<std::pair<long long const, HPHP::StringData const*>, long long const>> = {}, },
_M_eq = {<std::binary_function<long long, long long, bool>> = {}, }, _M_h1 = {},
_M_h2 = {}}, <std::tr1::__detail::_Map_base<long long, std::pair<long long const, HPHP::StringData const*>, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, true, std::tr1::_Hashtable<long long, std::pair<long long const, HPHP::StringData const*>, std::allocator<std::pair<long long const, HPHP::StringData const*> >, std::_Select1st<std::pair<long long const, HPHP::StringData const*> >, std::equal_to, HPHP::int64_hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true> >> = {},
_M_node_allocator = {<__gnu_cxx::new_allocator<std::tr1::__detail::_Hash_node<std::pair<long long const, HPHP::StringData const*>, false> >> = {}, }, _M_buckets = 0x0, _M_bucket_count = 0, _M_element_count = 0, _M_rehash_policy = {_M_max_load_factor = 0, _M_growth_factor = 0,
_M_next_resize = 0}}, }, }, }

davidpenn · 2012-09-10T15:10:01Z

The Problem looks to be in integer_string_data_map.find() function when calling

std::size_t __n = this->_M_bucket_index(__k, __code, _M_bucket_count); _M_bucket_count is 0 and the next function in the stack is trying to return a modulo return __num % __den;

As a work around until this bug is fixed you can incase the integer in your code inside ''

Should compile and run just fine without SIGFPE

neilnacario · 2012-09-24T19:43:57Z

This is a case of static initialization order problem.

The static variable

static int ATTRIBUTE_UNUSED initIntegers = precompute_integers();

of the generated sys/cpputil.cpp gets initialized before String::integer_string_data_map.
Problem here is that precompute_integers() indirectly uses String::integer_string_data_map.
the following changes works with the above test case:

type_string.h:

    diff --git a/src/runtime/base/type_string.h b/src/runtime/base/type_string.h
    index 6631ad3..9cc7894 100644
    --- a/src/runtime/base/type_string.h
    +++ b/src/runtime/base/type_string.h
    @@ -60,7 +60,10 @@ public:
       static const int MaxPrecomputedInteger = 65535;
       static StringData *converted_integers_raw;
       static StringData *converted_integers;
    -  static IntegerStringDataMap integer_string_data_map;
    +  static IntegerStringDataMap& GetIntegerStringDataMap(){ 
    +   static IntegerStringDataMap integer_string_data_map;
    +   return integer_string_data_map;
    +  }

       static bool HasConverted(int64 n) {
         return MinPrecomputedInteger <= n && n <= MaxPrecomputedInteger;
    @@ -80,6 +83,7 @@ public:
           const StringData *sd = converted_integers + n;
           return sd;
         }
    +    IntegerStringDataMap& integer_string_data_map = GetIntegerStringDataMap();
         IntegerStringDataMap::const_iterator it =
           integer_string_data_map.find(n);
         if (it != integer_string_data_map.end()) return it->second;

type_string.cpp:

    diff --git a/src/runtime/base/type_string.cpp b/src/runtime/base/type_string.cpp
    index 5e53eec..f7e80f3 100644
    --- a/src/runtime/base/type_string.cpp
    +++ b/src/runtime/base/type_string.cpp
    @@ -41,7 +41,6 @@ const StaticString empty_string("");
     StringData *String::converted_integers_raw;
     StringData *String::converted_integers;

    -String::IntegerStringDataMap String::integer_string_data_map;

     const StringData *convert_integer_helper(int64 n, StringData *sd) {
       char tmpbuf[21];
    @@ -64,6 +63,7 @@ const StringData *convert_integer_helper(int64 n, StringData *sd) {
     }

     void String::PreConvertInteger(int64 n) {
    +  IntegerStringDataMap& integer_string_data_map = GetIntegerStringDataMap();
       IntegerStringDataMap::const_iterator it =
         integer_string_data_map.find(n);
       if (it != integer_string_data_map.end()) return;

boundless08 · 2012-11-16T11:48:19Z

I'm having the same problem with my build. It compiles fine but throws the exception when I run the program as a server. I tried the fix above by @neilnacario but the same thing happened. Do I need to remake Hiphop for it to take effect?

EDIT: After posting I realise it was a stupid question, rebuilding it now.

EDIT AGAIN: It works after the post above, thanks @neilnacario

ptarjan · 2013-05-13T21:32:40Z

We're closing out all bugs older than 2 months. http://www.hiphop-php.com/wp/?p=575

If this is still an issue, please re-open it, and in order of goodness:

Give detailed repro steps
Write a test case in hphp/tests/quick (run it with hphp/tests/run) and send the pull request
Fix it in a pull request

ptarjan closed this as completed May 13, 2013

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Floating Point Exception #570

Floating Point Exception #570

superdav42 commented Aug 29, 2012

sgolemon commented Aug 30, 2012

superdav42 commented Sep 1, 2012

d3xt3r01 commented Sep 1, 2012

thedjnK commented Sep 1, 2012

d3xt3r01 commented Sep 1, 2012

WhiteRabbit-Code commented Sep 4, 2012

thedjnK commented Sep 7, 2012

davidpenn commented Sep 7, 2012

davidpenn commented Sep 10, 2012

neilnacario commented Sep 24, 2012

boundless08 commented Nov 16, 2012

ptarjan commented May 13, 2013

Floating Point Exception #570

Floating Point Exception #570

Comments

superdav42 commented Aug 29, 2012

sgolemon commented Aug 30, 2012

superdav42 commented Sep 1, 2012

d3xt3r01 commented Sep 1, 2012

thedjnK commented Sep 1, 2012

d3xt3r01 commented Sep 1, 2012

WhiteRabbit-Code commented Sep 4, 2012

thedjnK commented Sep 7, 2012

davidpenn commented Sep 7, 2012

davidpenn commented Sep 10, 2012

neilnacario commented Sep 24, 2012

boundless08 commented Nov 16, 2012

ptarjan commented May 13, 2013