From dreiss@REDACTED Wed Jul 1 04:34:39 2009 From: dreiss@REDACTED (David Reiss) Date: Tue, 30 Jun 2009 19:34:39 -0700 Subject: Per-thread FPE pointer not being initialized Message-ID: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> The per-thread last floating point exception pointer is not initialized to NULL when it is allocated. As a result, spurious floating point exceptions are reported. This is 100% reproducible for me on CentOS 5.1 for x86-64, with Erlang/OTP R13B built from source with gcc 2.5 and gcc 4.1.2. It doesn't happen with R13B01, but, based on the nature of the bug, I think that is most likely due to chance. Steps to reproduce: 1/ Start up a node with dreiss@REDACTED:~$ erl -noshell -name bob@`hostname` 2/ Build and compile test program dreiss@REDACTED:~$ cat test.erl -module(test). -export([start/1]). start([Remote]) -> rpc:call(Remote, erlang, is_float, [750.0]). dreiss@REDACTED:~$ erlc test.erl 3/ Run test program dreiss@REDACTED:~$ erl -noshell -name alice@`hostname` -pz . -s test start bob@`hostname` -s init stop The "alice" node exits with no output. After running the "alice" command, the "bob" node prints the following ERTS_FP_CHECK_INIT at 0x4aaded: detected unhandled FPE at 0x2 Patch: diff otp_src_R13B/erts/emulator/sys/unix/sys_float.c otp_src_R13B/sys/unix/sys_float.c/sys/unix/sys_float.c --- otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 17:53:31.000000000 -0700 +++ otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 17:53:31.000000000 -0700 @@ -57,7 +57,8 @@ void erts_thread_init_fp_exception(void) { unsigned long *fpe = erts_alloc(ERTS_ALC_T_FP_EXCEPTION, sizeof(*fpe)); + *fpe = 0; erts_tsd_set(fpe_key, fpe); } --David From raimo+erlang-patches@REDACTED Wed Jul 1 10:07:15 2009 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Wed, 1 Jul 2009 10:07:15 +0200 Subject: [erlang-patches] Per-thread FPE pointer not being initialized In-Reply-To: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> References: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> Message-ID: <20090701080715.GA17444@erix.ericsson.se> I can not reproduce it - that would need exact match of floating point exception vs signals i guess. I see no harm ininitializing an allocated buffer (except for performance) but suspect the bug might be elswhere. The patch is scheduled for R13B02 and I will check with the guys that know better if the fix should be somewhere else... On Tue, Jun 30, 2009 at 07:34:39PM -0700, David Reiss wrote: > The per-thread last floating point exception pointer is not initialized to > NULL when it is allocated. As a result, spurious floating point > exceptions are reported. > > This is 100% reproducible for me on CentOS 5.1 for x86-64, with Erlang/OTP > R13B built from source with gcc 2.5 and gcc 4.1.2. It doesn't happen with > R13B01, but, based on the nature of the bug, I think that is most likely > due to chance. > > Steps to reproduce: > > 1/ Start up a node with > dreiss@REDACTED:~$ erl -noshell -name bob@`hostname` > > 2/ Build and compile test program > dreiss@REDACTED:~$ cat test.erl > -module(test). > -export([start/1]). > start([Remote]) -> > rpc:call(Remote, erlang, is_float, [750.0]). > dreiss@REDACTED:~$ erlc test.erl > > 3/ Run test program > dreiss@REDACTED:~$ erl -noshell -name alice@`hostname` -pz . -s test > start bob@`hostname` -s init stop > > The "alice" node exits with no output. After running the "alice" command, > the "bob" node prints the following > > ERTS_FP_CHECK_INIT at 0x4aaded: detected unhandled FPE at 0x2 > > Patch: > > diff otp_src_R13B/erts/emulator/sys/unix/sys_float.c > otp_src_R13B/sys/unix/sys_float.c/sys/unix/sys_float.c > --- otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > 17:53:31.000000000 -0700 > +++ otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > 17:53:31.000000000 -0700 > @@ -57,7 +57,8 @@ > void erts_thread_init_fp_exception(void) > { > unsigned long *fpe = erts_alloc(ERTS_ALC_T_FP_EXCEPTION, sizeof(*fpe)); > + *fpe = 0; > erts_tsd_set(fpe_key, fpe); > } > > > > --David > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo+erlang-patches@REDACTED Wed Jul 1 10:52:35 2009 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Wed, 1 Jul 2009 10:52:35 +0200 Subject: [erlang-patches] Patch to add Blowfish cfb64 to crypto app In-Reply-To: References: Message-ID: <20090701085235.GB17444@erix.ericsson.se> On Sat, Jun 27, 2009 at 11:45:24AM +0100, Paul Oliver wrote: > Hi all, > > Please find attached a patch to add Blowfish cfb64 to the crypto app. > This has been tested on Linux only. > > Patch is against R13B01. > > Any feedback greatly appreciated. Thank you very much! Generally these kind of patches (tested on Linux) create problems for us since we strive to support also Solaris, {Free,Open}BSD, etc... and sometimes they lag behind in OpenSSL version. Furthermore the crypto application is not yet dynamic about what it can do. It could be made but that remains to be done. But Blowfish CFB64 is as far as I can see supported on all openssl versions we have to be prepared for... We will try to squeeze your patch into R13B02. > > Cheers, > Paul. > *** /tmp/erlang-otp/lib/crypto/c_src/crypto_drv.c 2009-06-25 08:29:05.000000000 +0100 > --- lib/crypto/c_src/crypto_drv.c 2009-06-25 16:21:54.000000000 +0100 > *************** > *** 52,57 **** > --- 52,58 ---- > #include > #include > #include > + #include > > #ifdef DEBUG > # define ASSERT(e) \ > *************** static ErlDrvEntry crypto_driver_entry = > *** 209,214 **** > --- 210,218 ---- > #define DRV_SHA512_FINAL 58 > #endif > > + #define DRV_BF_CFB64_ENCRYPT 59 > + #define DRV_BF_CFB64_DECRYPT 60 > + > /* #define DRV_CBC_IDEA_ENCRYPT 34 */ > /* #define DRV_CBC_IDEA_DECRYPT 35 */ > > *************** static int control(ErlDrvData drv_data, > *** 354,360 **** > int prime_len, generator; > int privkey_len, pubkey_len, dh_p_len, dh_g_len; > unsigned int rsa_s_len, j; > ! char *key, *key2, *dbuf, *p; > const_DES_cblock *des_key, *des_key2, *des_key3; > const unsigned char *des_dbuf; > BIGNUM *bn_from, *bn_to, *bn_rand, *bn_result; > --- 358,364 ---- > int prime_len, generator; > int privkey_len, pubkey_len, dh_p_len, dh_g_len; > unsigned int rsa_s_len, j; > ! char *key, *key2, *dbuf, *p, *ivec; > const_DES_cblock *des_key, *des_key2, *des_key3; > const unsigned char *des_dbuf; > BIGNUM *bn_from, *bn_to, *bn_rand, *bn_result; > *************** static int control(ErlDrvData drv_data, > *** 369,374 **** > --- 373,388 ---- > /* IDEA_KEY_SCHEDULE idea, idea2; */ > unsigned char hmacbuf[SHA_DIGEST_LENGTH]; > unsigned char *rsa_s, *dsa_s; > + /* blowfish ivec */ > + unsigned char bf_tkey[8]; > + /* blowfish ivec pos */ > + int bf_n; > + /* blowfish direction */ > + int bf_direction; > + /* blowfish input data */ > + const unsigned char *bf_dbuf; > + /* blowfish key 8 */ > + BF_KEY bf_key; > /* char hmacbuf[SHA_LEN]; */ > #if SSL_VERSION_0_9_8 > SHA256_CTX sha256_ctx; > *************** static int control(ErlDrvData drv_data, > *** 503,508 **** > --- 517,541 ---- > (command == DRV_CBC_DES_ENCRYPT)); > return dlen; > > + case DRV_BF_CFB64_ENCRYPT: > + case DRV_BF_CFB64_DECRYPT: > + /* buf = klen[4] key ivec[8] data */ > + klen = get_int32(buf); > + key = buf + 4; > + ivec = key + klen; > + bf_dbuf = ivec + 8; > + dlen = len - 4 - klen - 8; > + if (dlen < 0) > + return -1; > + BF_set_key(&bf_key, klen, key); > + memcpy(bf_tkey, ivec, 8); > + bin = return_binary(rbuf,rlen,dlen); > + if (bin==NULL) return -1; > + bf_direction = command == DRV_BF_CFB64_ENCRYPT ? BF_ENCRYPT : BF_DECRYPT; > + bf_n = 0; > + BF_cfb64_encrypt(bf_dbuf, bin, dlen, &bf_key, bf_tkey, &bf_n, bf_direction); > + return dlen; > + > /* case DRV_CBC_IDEA_ENCRYPT: */ > /* case DRV_CBC_IDEA_DECRYPT: */ > /* buf = key[16] ivec[8] data */ > *** /tmp/erlang-otp/lib/crypto/doc/src/crypto.xml 2009-06-25 08:29:05.000000000 +0100 > --- lib/crypto/doc/src/crypto.xml 2009-06-27 10:51:47.000000000 +0100 > *************** Mpint() = *** 324,329 **** > --- 324,359 ---- > > > > + blowfish_cfb64_encrypt(Key, IVec, Text) -> Cipher > + Encrypt Textusing Blowfish in CFB mode with 64 > + bit feedback > + > + Key = Text = iolist() | binary() > + IVec = Cipher = binary() > + > + > +

Encrypts Text using Blowfish in CFB mode with 64 bit > + feedback. Key is the Blowfish key, and IVec is an > + arbitrary initializing vector. The length of IVec > + must be 64 bits (8 bytes).

> +
> +
> + > + blowfish_cfb64_decrypt(Key, IVec, Text) -> Cipher > + Decrypt Textusing Blowfish in CFB mode with 64 > + bit feedback > + > + Key = Text = iolist() | binary() > + IVec = Cipher = binary() > + > + > +

Decrypts Text using Blowfish in CFB mode with 64 bit > + feedback. Key is the Blowfish key, and IVec is an > + arbitrary initializing vector. The length of IVec > + must be 64 bits (8 bytes).

> +
> +
> + > aes_cfb_128_encrypt(Key, IVec, Text) -> Cipher > aes_cbc_128_encrypt(Key, IVec, Text) -> Cipher > Encrypt Textaccording to AES in Cipher Feedback mode or Cipher Block Chaining mode > *** /tmp/erlang-otp/lib/crypto/src/crypto.erl 2009-06-25 08:29:05.000000000 +0100 > --- lib/crypto/src/crypto.erl 2009-06-27 10:53:24.000000000 +0100 > *************** > *** 30,35 **** > --- 30,36 ---- > -export([md5_mac/2, md5_mac_96/2, sha_mac/2, sha_mac_96/2]). > -export([des_cbc_encrypt/3, des_cbc_decrypt/3, des_cbc_ivec/1]). > -export([des3_cbc_encrypt/5, des3_cbc_decrypt/5]). > + -export([blowfish_cfb64_encrypt/3,blowfish_cfb64_decrypt/3]). > -export([des_ede3_cbc_encrypt/5, des_ede3_cbc_decrypt/5]). > -export([aes_cfb_128_encrypt/3, aes_cfb_128_decrypt/3]). > -export([exor/2]). > *************** > *** 111,116 **** > --- 112,119 ---- > %% -define(SHA512_UPDATE, 57). > %% -define(SHA512_FINAL, 58). > > + -define(BF_CFB64_ENCRYPT, 59). > + -define(BF_CFB64_DECRYPT, 60). > > %% -define(IDEA_CBC_ENCRYPT, 34). > %% -define(IDEA_CBC_DECRYPT, 35). > *************** des_ede3_cbc_decrypt(Key1, Key2, Key3, I > *** 297,302 **** > --- 300,314 ---- > control(?DES_EDE3_CBC_DECRYPT, [Key1, Key2, Key3, IVec, Data]). > > %% > + %% Blowfish > + %% > + blowfish_cfb64_encrypt(Key, IVec, Data) -> > + control_bin(?BF_CFB64_ENCRYPT, Key, list_to_binary([IVec, Data])). > + > + blowfish_cfb64_decrypt(Key, IVec, Data) -> > + control_bin(?BF_CFB64_DECRYPT, Key, list_to_binary([IVec, Data])). > + > + %% > %% AES in cipher feedback mode (CFB) > %% > aes_cfb_128_encrypt(Key, IVec, Data) -> > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From mikpe@REDACTED Wed Jul 1 12:03:04 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 1 Jul 2009 12:03:04 +0200 Subject: [erlang-patches] Per-thread FPE pointer not being initialized In-Reply-To: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> References: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> Message-ID: <19019.13400.316967.146367@pilspetsen.it.uu.se> David Reiss writes: > The per-thread last floating point exception pointer is not initialized to > NULL when it is allocated. As a result, spurious floating point > exceptions are reported. > > This is 100% reproducible for me on CentOS 5.1 for x86-64, with Erlang/OTP > R13B built from source with gcc 2.5 and gcc 4.1.2. It doesn't happen with > R13B01, but, based on the nature of the bug, I think that is most likely > due to chance. > > Steps to reproduce: > > 1/ Start up a node with > dreiss@REDACTED:~$ erl -noshell -name bob@`hostname` > > 2/ Build and compile test program > dreiss@REDACTED:~$ cat test.erl > -module(test). > -export([start/1]). > start([Remote]) -> > rpc:call(Remote, erlang, is_float, [750.0]). > dreiss@REDACTED:~$ erlc test.erl > > 3/ Run test program > dreiss@REDACTED:~$ erl -noshell -name alice@`hostname` -pz . -s test > start bob@`hostname` -s init stop > > The "alice" node exits with no output. After running the "alice" command, > the "bob" node prints the following > > ERTS_FP_CHECK_INIT at 0x4aaded: detected unhandled FPE at 0x2 > > Patch: > > diff otp_src_R13B/erts/emulator/sys/unix/sys_float.c > otp_src_R13B/sys/unix/sys_float.c/sys/unix/sys_float.c > --- otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > 17:53:31.000000000 -0700 > +++ otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > 17:53:31.000000000 -0700 > @@ -57,7 +57,8 @@ > void erts_thread_init_fp_exception(void) > { > unsigned long *fpe = erts_alloc(ERTS_ALC_T_FP_EXCEPTION, sizeof(*fpe)); > + *fpe = 0; > erts_tsd_set(fpe_key, fpe); > } Thanks, that bug was mine :-( Your fix is correct. I believe the initialisation here wasn't needed originally, but became necessary as a side effect of some FP exn machinery redesign I did late last year. Where did the spurious FP exception get detected, i.e., what runtime system procedure does 0x4aaded correspond to? /Mikael From raimo+erlang-patches@REDACTED Wed Jul 1 13:37:59 2009 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Wed, 1 Jul 2009 13:37:59 +0200 Subject: [erlang-patches] Per-thread FPE pointer not being initialized In-Reply-To: <19019.13400.316967.146367@pilspetsen.it.uu.se> References: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> <19019.13400.316967.146367@pilspetsen.it.uu.se> Message-ID: <20090701113759.GA16234@erix.ericsson.se> On Wed, Jul 01, 2009 at 12:03:04PM +0200, Mikael Pettersson wrote: > David Reiss writes: > > The per-thread last floating point exception pointer is not initialized to > > NULL when it is allocated. As a result, spurious floating point > > exceptions are reported. > > > > This is 100% reproducible for me on CentOS 5.1 for x86-64, with Erlang/OTP > > R13B built from source with gcc 2.5 and gcc 4.1.2. It doesn't happen with > > R13B01, but, based on the nature of the bug, I think that is most likely > > due to chance. > > > > Steps to reproduce: > > > > 1/ Start up a node with > > dreiss@REDACTED:~$ erl -noshell -name bob@`hostname` > > > > 2/ Build and compile test program > > dreiss@REDACTED:~$ cat test.erl > > -module(test). > > -export([start/1]). > > start([Remote]) -> > > rpc:call(Remote, erlang, is_float, [750.0]). > > dreiss@REDACTED:~$ erlc test.erl > > > > 3/ Run test program > > dreiss@REDACTED:~$ erl -noshell -name alice@`hostname` -pz . -s test > > start bob@`hostname` -s init stop > > > > The "alice" node exits with no output. After running the "alice" command, > > the "bob" node prints the following > > > > ERTS_FP_CHECK_INIT at 0x4aaded: detected unhandled FPE at 0x2 > > > > Patch: > > > > diff otp_src_R13B/erts/emulator/sys/unix/sys_float.c > > otp_src_R13B/sys/unix/sys_float.c/sys/unix/sys_float.c > > --- otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > > 17:53:31.000000000 -0700 > > +++ otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > > 17:53:31.000000000 -0700 > > @@ -57,7 +57,8 @@ > > void erts_thread_init_fp_exception(void) > > { > > unsigned long *fpe = erts_alloc(ERTS_ALC_T_FP_EXCEPTION, sizeof(*fpe)); > > + *fpe = 0; > > erts_tsd_set(fpe_key, fpe); > > } > > Thanks, that bug was mine :-( Your fix is correct. Would your patch in http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1380 also solve this problem? Or are both needed? --- otp-0622/erts/emulator/sys/unix/sys_float.c.~1~ 2009-02-26 11:45:48.000000000 +0100 +++ otp-0622/erts/emulator/sys/unix/sys_float.c 2009-06-26 11:14:15.000000000 +0200 @@ -792,6 +792,8 @@ sys_chars_to_double(char* buf, double* f int matherr(struct exception *exc) { +#if !defined(NO_FPE_SIGNALS) set_current_fp_exception((unsigned long)__builtin_return_address(0)); +#endif return 1; } > > I believe the initialisation here wasn't needed originally, > but became necessary as a side effect of some FP exn machinery > redesign I did late last year. > > Where did the spurious FP exception get detected, i.e., > what runtime system procedure does 0x4aaded correspond to? > > /Mikael > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From mikpe@REDACTED Wed Jul 1 13:55:39 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 1 Jul 2009 13:55:39 +0200 Subject: [erlang-patches] Per-thread FPE pointer not being initialized In-Reply-To: <20090701113759.GA16234@erix.ericsson.se> References: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> <19019.13400.316967.146367@pilspetsen.it.uu.se> <20090701113759.GA16234@erix.ericsson.se> Message-ID: <19019.20155.166546.917924@pilspetsen.it.uu.se> Raimo Niskanen writes: > On Wed, Jul 01, 2009 at 12:03:04PM +0200, Mikael Pettersson wrote: > > David Reiss writes: > > > The per-thread last floating point exception pointer is not initialized to > > > NULL when it is allocated. As a result, spurious floating point > > > exceptions are reported. > > > > > > This is 100% reproducible for me on CentOS 5.1 for x86-64, with Erlang/OTP > > > R13B built from source with gcc 2.5 and gcc 4.1.2. It doesn't happen with > > > R13B01, but, based on the nature of the bug, I think that is most likely > > > due to chance. > > > > > > Steps to reproduce: > > > > > > 1/ Start up a node with > > > dreiss@REDACTED:~$ erl -noshell -name bob@`hostname` > > > > > > 2/ Build and compile test program > > > dreiss@REDACTED:~$ cat test.erl > > > -module(test). > > > -export([start/1]). > > > start([Remote]) -> > > > rpc:call(Remote, erlang, is_float, [750.0]). > > > dreiss@REDACTED:~$ erlc test.erl > > > > > > 3/ Run test program > > > dreiss@REDACTED:~$ erl -noshell -name alice@`hostname` -pz . -s test > > > start bob@`hostname` -s init stop > > > > > > The "alice" node exits with no output. After running the "alice" command, > > > the "bob" node prints the following > > > > > > ERTS_FP_CHECK_INIT at 0x4aaded: detected unhandled FPE at 0x2 > > > > > > Patch: > > > > > > diff otp_src_R13B/erts/emulator/sys/unix/sys_float.c > > > otp_src_R13B/sys/unix/sys_float.c/sys/unix/sys_float.c > > > --- otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > > > 17:53:31.000000000 -0700 > > > +++ otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > > > 17:53:31.000000000 -0700 > > > @@ -57,7 +57,8 @@ > > > void erts_thread_init_fp_exception(void) > > > { > > > unsigned long *fpe = erts_alloc(ERTS_ALC_T_FP_EXCEPTION, sizeof(*fpe)); > > > + *fpe = 0; > > > erts_tsd_set(fpe_key, fpe); > > > } > > > > Thanks, that bug was mine :-( Your fix is correct. > > Would your patch in http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1380 > also solve this problem? Or are both needed? > > --- otp-0622/erts/emulator/sys/unix/sys_float.c.~1~ 2009-02-26 11:45:48.000000000 +0100 > +++ otp-0622/erts/emulator/sys/unix/sys_float.c 2009-06-26 11:14:15.000000000 +0200 > @@ -792,6 +792,8 @@ sys_chars_to_double(char* buf, double* f > int > matherr(struct exception *exc) > { > +#if !defined(NO_FPE_SIGNALS) > set_current_fp_exception((unsigned long)__builtin_return_address(0)); > +#endif > return 1; > } The two patches fix independent issues. The #if !defined change in sys_chars_to_double() fixes a compile/link error with !gcc. /Mikael From raimo+erlang-patches@REDACTED Wed Jul 1 17:16:24 2009 From: raimo+erlang-patches@REDACTED (Raimo Niskanen) Date: Wed, 1 Jul 2009 17:16:24 +0200 Subject: [erlang-patches] Per-thread FPE pointer not being initialized In-Reply-To: <19019.20155.166546.917924@pilspetsen.it.uu.se> References: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> <19019.13400.316967.146367@pilspetsen.it.uu.se> <20090701113759.GA16234@erix.ericsson.se> <19019.20155.166546.917924@pilspetsen.it.uu.se> Message-ID: <20090701151624.GA19459@erix.ericsson.se> On Wed, Jul 01, 2009 at 01:55:39PM +0200, Mikael Pettersson wrote: > Raimo Niskanen writes: > > On Wed, Jul 01, 2009 at 12:03:04PM +0200, Mikael Pettersson wrote: > > > David Reiss writes: > > > > The per-thread last floating point exception pointer is not initialized to > > > > NULL when it is allocated. As a result, spurious floating point > > > > exceptions are reported. > > > > > > > > This is 100% reproducible for me on CentOS 5.1 for x86-64, with Erlang/OTP > > > > R13B built from source with gcc 2.5 and gcc 4.1.2. It doesn't happen with > > > > R13B01, but, based on the nature of the bug, I think that is most likely > > > > due to chance. > > > > > > > > Steps to reproduce: > > > > > > > > 1/ Start up a node with > > > > dreiss@REDACTED:~$ erl -noshell -name bob@`hostname` > > > > > > > > 2/ Build and compile test program > > > > dreiss@REDACTED:~$ cat test.erl > > > > -module(test). > > > > -export([start/1]). > > > > start([Remote]) -> > > > > rpc:call(Remote, erlang, is_float, [750.0]). > > > > dreiss@REDACTED:~$ erlc test.erl > > > > > > > > 3/ Run test program > > > > dreiss@REDACTED:~$ erl -noshell -name alice@`hostname` -pz . -s test > > > > start bob@`hostname` -s init stop > > > > > > > > The "alice" node exits with no output. After running the "alice" command, > > > > the "bob" node prints the following > > > > > > > > ERTS_FP_CHECK_INIT at 0x4aaded: detected unhandled FPE at 0x2 > > > > > > > > Patch: > > > > > > > > diff otp_src_R13B/erts/emulator/sys/unix/sys_float.c > > > > otp_src_R13B/sys/unix/sys_float.c/sys/unix/sys_float.c > > > > --- otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > > > > 17:53:31.000000000 -0700 > > > > +++ otp_src_R13B/erts/emulator/sys/unix/sys_float.c 2009-06-30 > > > > 17:53:31.000000000 -0700 > > > > @@ -57,7 +57,8 @@ > > > > void erts_thread_init_fp_exception(void) > > > > { > > > > unsigned long *fpe = erts_alloc(ERTS_ALC_T_FP_EXCEPTION, sizeof(*fpe)); > > > > + *fpe = 0; > > > > erts_tsd_set(fpe_key, fpe); > > > > } > > > > > > Thanks, that bug was mine :-( Your fix is correct. > > > > Would your patch in http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1380 > > also solve this problem? Or are both needed? > > > > --- otp-0622/erts/emulator/sys/unix/sys_float.c.~1~ 2009-02-26 11:45:48.000000000 +0100 > > +++ otp-0622/erts/emulator/sys/unix/sys_float.c 2009-06-26 11:14:15.000000000 +0200 > > @@ -792,6 +792,8 @@ sys_chars_to_double(char* buf, double* f > > int > > matherr(struct exception *exc) > > { > > +#if !defined(NO_FPE_SIGNALS) > > set_current_fp_exception((unsigned long)__builtin_return_address(0)); > > +#endif > > return 1; > > } > > The two patches fix independent issues. The #if !defined change in > sys_chars_to_double() fixes a compile/link error with !gcc. Sorry I misread the patch. I accidentally saw it add set_current_fp_exception(0) to matherr(exc) but it only added preprocessor directives... > > /Mikael > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From dreiss@REDACTED Wed Jul 1 20:08:02 2009 From: dreiss@REDACTED (David Reiss) Date: Wed, 1 Jul 2009 11:08:02 -0700 Subject: [erlang-patches] Per-thread FPE pointer not being initialized In-Reply-To: <20090701151624.GA19459@erix.ericsson.se> References: <21ae77030906301934q7984e49amfa692204af71568a@mail.gmail.com> <19019.13400.316967.146367@pilspetsen.it.uu.se> <20090701113759.GA16234@erix.ericsson.se> <19019.20155.166546.917924@pilspetsen.it.uu.se> <20090701151624.GA19459@erix.ericsson.se> Message-ID: <21ae77030907011108n3b527543ha3a573faedea33a3@mail.gmail.com> > Where did the spurious FP exception get detected, i.e., > what runtime system procedure does 0x4aaded correspond to? It looks like it is dec_term (and gdb reports it as line 1206 of beam/external.c, which is a call to sys_chars_to_double). When I first detected the problem, it was in the context of a larger application. The reported address was 0x51d507, which is in sys_chars_to_double. The boundaries get a bit blurred in optimized builds. :) --David On Wed, Jul 1, 2009 at 8:16 AM, Raimo Niskanen wrote: > On Wed, Jul 01, 2009 at 01:55:39PM +0200, Mikael Pettersson wrote: >> Raimo Niskanen writes: >> ?> On Wed, Jul 01, 2009 at 12:03:04PM +0200, Mikael Pettersson wrote: >> ?> > David Reiss writes: >> ?> > ?> The per-thread last floating point exception pointer is not initialized to >> ?> > ?> NULL when it is allocated. ?As a result, spurious floating point >> ?> > ?> exceptions are reported. >> ?> > ?> >> ?> > ?> This is 100% reproducible for me on CentOS 5.1 for x86-64, with Erlang/OTP >> ?> > ?> R13B built from source with gcc 2.5 and gcc 4.1.2. ?It doesn't happen with >> ?> > ?> R13B01, but, based on the nature of the bug, I think that is most likely >> ?> > ?> due to chance. >> ?> > ?> >> ?> > ?> Steps to reproduce: >> ?> > ?> >> ?> > ?> 1/ Start up a node with >> ?> > ?> ? dreiss@REDACTED:~$ erl -noshell -name bob@`hostname` >> ?> > ?> >> ?> > ?> 2/ Build and compile test program >> ?> > ?> ? dreiss@REDACTED:~$ cat test.erl >> ?> > ?> ? -module(test). >> ?> > ?> ? -export([start/1]). >> ?> > ?> ? start([Remote]) -> >> ?> > ?> ? ? rpc:call(Remote, erlang, is_float, [750.0]). >> ?> > ?> ? dreiss@REDACTED:~$ erlc test.erl >> ?> > ?> >> ?> > ?> 3/ Run test program >> ?> > ?> ? dreiss@REDACTED:~$ erl -noshell -name alice@`hostname` -pz . -s test >> ?> > ?> start bob@`hostname` -s init stop >> ?> > ?> >> ?> > ?> The "alice" node exits with no output. ?After running the "alice" command, >> ?> > ?> the "bob" node prints the following >> ?> > ?> >> ?> > ?> ? ERTS_FP_CHECK_INIT at 0x4aaded: detected unhandled FPE at 0x2 >> ?> > ?> >> ?> > ?> Patch: >> ?> > ?> >> ?> > ?> diff otp_src_R13B/erts/emulator/sys/unix/sys_float.c >> ?> > ?> otp_src_R13B/sys/unix/sys_float.c/sys/unix/sys_float.c >> ?> > ?> --- otp_src_R13B/erts/emulator/sys/unix/sys_float.c ? 2009-06-30 >> ?> > ?> 17:53:31.000000000 -0700 >> ?> > ?> +++ otp_src_R13B/erts/emulator/sys/unix/sys_float.c ? 2009-06-30 >> ?> > ?> 17:53:31.000000000 -0700 >> ?> > ?> @@ -57,7 +57,8 @@ >> ?> > ?> ?void erts_thread_init_fp_exception(void) >> ?> > ?> ?{ >> ?> > ?> ? ? ?unsigned long *fpe = erts_alloc(ERTS_ALC_T_FP_EXCEPTION, sizeof(*fpe)); >> ?> > ?> + ? ?*fpe = 0; >> ?> > ?> ? ? ?erts_tsd_set(fpe_key, fpe); >> ?> > ?> ?} >> ?> > >> ?> > Thanks, that bug was mine :-( Your fix is correct. >> ?> >> ?> Would your patch in http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1380 >> ?> also solve this problem? Or are both needed? >> ?> >> ?> --- otp-0622/erts/emulator/sys/unix/sys_float.c.~1~ ? ? ? ?2009-02-26 11:45:48.000000000 +0100 >> ?> +++ otp-0622/erts/emulator/sys/unix/sys_float.c ? ?2009-06-26 11:14:15.000000000 +0200 >> ?> @@ -792,6 +792,8 @@ sys_chars_to_double(char* buf, double* f >> ?> ?int >> ?> ?matherr(struct exception *exc) >> ?> ?{ >> ?> +#if !defined(NO_FPE_SIGNALS) >> ?> ? ? ?set_current_fp_exception((unsigned long)__builtin_return_address(0)); >> ?> +#endif >> ?> ? ? ?return 1; >> ?> ?} >> >> The two patches fix independent issues. The #if !defined change in >> sys_chars_to_double() fixes a compile/link error with !gcc. > > Sorry I misread the patch. I accidentally saw it add > set_current_fp_exception(0) to matherr(exc) but it > only added preprocessor directives... > >> >> /Mikael >> >> ________________________________________________________________ >> erlang-patches mailing list. See http://www.erlang.org/faq.html >> erlang-patches (at) erlang.org > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > ________________________________________________________________ > erlang-patches mailing list. See http://www.erlang.org/faq.html > erlang-patches (at) erlang.org > > From dgud@REDACTED Mon Jul 6 11:05:49 2009 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 06 Jul 2009 11:05:49 +0200 Subject: [erlang-bugs] Re: PATCH - public_key should handle unknown attribute types In-Reply-To: References: Message-ID: <4A51BE6D.1090705@erix.ericsson.se> Thanks applied. /Dan Will wrote: > Odd, gmail clearly shows the diff attached, but it doesn't seem to > have made it through the mailing list processing. Here's an inline > copy... > > On Sat, Jul 4, 2009 at 11:01 AM, Will wrote: >> Hi, >> >> SSL handshaking with new_ssl will fail when a certificate contains >> attributes unknown to the public_key module. Here is a patch that >> leaves the attribute value encoded when its type is unknown. >> >> -Will >> > > diff -r 80795205fd0a src/pubkey_cert_records.erl > --- a/src/pubkey_cert_records.erl Sat Jul 04 10:44:41 2009 -0700 > +++ b/src/pubkey_cert_records.erl Sat Jul 04 10:51:40 2009 -0700 > @@ -187,8 +187,11 @@ > end, Exts). > > transform(#'AttributeTypeAndValue'{type=Id,value=Value0} = ATAV, Func) -> > - Type = attribute_type(Id), > - {ok, Value} = 'OTP-PUB-KEY':Func(Type, Value0), > + {ok, Value} = > + case attribute_type(Id) of > + Type when is_atom(Type) -> 'OTP-PUB-KEY':Func(Type, Value0); > + _UnknownType -> {ok, Value0} > + end, > ATAV#'AttributeTypeAndValue'{value=Value}; > transform(AKI = #'AuthorityKeyIdentifier'{authorityCertIssuer=ACI},Func) -> > AKI#'AuthorityKeyIdentifier'{authorityCertIssuer=transform(ACI,Func)}; > @@ -231,7 +234,8 @@ > attribute_type(?'id-at-serialNumber') -> 'X520SerialNumber'; > attribute_type(?'id-at-pseudonym') -> 'X520Pseudonym'; > attribute_type(?'id-domainComponent') -> 'DomainComponent'; > -attribute_type(?'id-emailAddress') -> 'EmailAddress'. > +attribute_type(?'id-emailAddress') -> 'EmailAddress'; > +attribute_type(Type) -> Type. > > %%% Old code transforms > > ________________________________________________________________ > erlang-bugs mailing list. See http://www.erlang.org/faq.html > erlang-bugs (at) erlang.org > From juhani@REDACTED Mon Jul 6 13:15:09 2009 From: juhani@REDACTED (=?ISO-8859-1?Q?Juhani_R=E4nkimies?=) Date: Mon, 6 Jul 2009 14:15:09 +0300 Subject: odbc unicode strings and datetime Message-ID: Hi, Attached are two patches to odbc module. The first one adds support for unicode text (nvarchar) fields. The second changes the handling of datetime fields so that it's possible to pass datetime data to odbc:param_query as {{Year,Month,Day},{Hour,Minute,Second}}. It also returns datetime fields from the database as tuples instead of strings which makes it backwards incompatible. Datetime patch should be applied on top of nvarchar patch. odbctest.erl contains an example of usage. I've tested with WinXP/MSSQL2008 and Win2003/MSSQL2008 Any comments are appreciated. The patches are made with git diff, hopefully the format is ok. Regards, Juhani R?nkimies -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.dephily@REDACTED Thu Jul 9 14:25:17 2009 From: vincent.dephily@REDACTED (Vincent de Phily) Date: Thu, 9 Jul 2009 14:25:17 +0200 Subject: http feature proposal: specifying which pid should receive async responses Message-ID: <200907091425.17599.vincent.dephily@mobile-devices.fr> (Re-sending here what I sent to erlang-questions, as this list seems more appropriate.) Hi, currently, http:request(...{sync,false}...) returns responses to the calling process. This is not allways convenient : sometimes we want another process to receive the response. It's possible work around this using spawn/receive machinery, but that's pointlessly painfull. This patch adds a 'reply_pid' option to http:request(), cleanly solving the problem : --- src/http.erl~ 2009-06-12 12:04:35.000000000 +0200 +++ src/http.erl 2009-07-08 18:53:47.000000000 +0200 @@ -284,6 +284,7 @@ HTTPRecordOptions = http_options(HTTPOptions, #http_options{}), Sync = proplists:get_value(sync, Options, true), + ReplyPid = proplists:get_value(reply_pid, Options, self()), NewHeaders = lists:map(fun({Key, Val}) -> {http_util:to_lower(Key), Val} end, Headers), @@ -296,7 +297,7 @@ _ -> RecordHeaders = header_record(NewHeaders, #http_request_h{}, Host, Version), - Request = #request{from = self(), + Request = #request{from = ReplyPid, scheme = Scheme, address = {Host,Port}, path = Path, The documentation would need to be updated too, but I'm not sure where to patch that. -- Vincent de Phily Mobile Devices +33 (0) 666 301 306 +33 (0) 142 119 325 Warning This message (and any associated files) is intended only for the use of its intended recipient and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author vincent.dephily@REDACTED and do not necessarily represent those of the company. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. From victor.ren@REDACTED Mon Jul 20 05:25:22 2009 From: victor.ren@REDACTED (Victor Ren) Date: Mon, 20 Jul 2009 11:25:22 +0800 Subject: Patch for Emacs erang-mode Message-ID: <6D2638F1A4681D49B2798FD89AABD830060B6735@ecnshmw511.eapac.ericsson.se> Hello, When erlang-mode is loaded, the templates defined in erlang-mode is added to tempo-tags (the default tags for all mode in Emacs). So unexpected template expansions may happen in other mode. I bind "space" with a function which expand the template when a tempo-tag is detected. In Emacs erlang-mode, when I input "if ", the if statement will be inserted automatically. But this also happen in other mode. I build a patch to fix this problem. The solution is to add tempo tags for elang-mode to a mode special taglist - erlang-tempo-tags and activiate these tags only in erlang-mode. *** /usr/lib/erlang/lib/tools-2.6.2/emacs/erlang.el Mon Jul 20 11:07:41 2009 --- /usr/erlang.el Mon Jul 20 11:07:45 2009 *************** *** 562,567 **** --- 562,570 ---- ;; Tempo skeleton templates: + (defvar erlang-tempo-tags nil + "Tempo tags for erlang mode") + (defvar erlang-skel '(("If" "if" erlang-skel-if) ("Case" "case" erlang-skel-case) *************** *** 2003,2008 **** --- 2006,2012 ---- (erlang-tags-init) (erlang-font-lock-init) (erlang-skel-init) + (tempo-use-tag-list 'erlang-tempo-tags) (run-hooks 'erlang-mode-hook) (if (zerop (buffer-size)) (run-hooks 'erlang-new-file-hook))) *************** *** 2888,2894 **** ;; variables describing the templates take effect ;; immdiately. (list (list 'erlang-skel-include (nth 2 (car skel)))) ! (nth 1 (car skel))) (setq menu (cons (erlang-skel-make-menu-item (car skel)) menu)))) (setq skel (cdr skel))) --- 2892,2900 ---- ;; variables describing the templates take effect ;; immdiately. (list (list 'erlang-skel-include (nth 2 (car skel)))) ! (nth 1 (car skel)) ! (car skel) ! 'erlang-tempo-tags) (setq menu (cons (erlang-skel-make-menu-item (car skel)) menu)))) (setq skel (cdr skel))) From dizzyd@REDACTED Mon Jul 27 21:49:21 2009 From: dizzyd@REDACTED (Dave Smith) Date: Mon, 27 Jul 2009 13:49:21 -0600 Subject: Missing HIPE modules in hipe.app Message-ID: Hi all... As a part of constructing an erlang embedded node, I found that the HIPE application is missing a number of modules from the .app file. Consequently, systools doesn't include those modules when the HIPE application is included in the release. I'm not sure if it's intentional or not, but thought I'd submit a patch against hipe.app (see attached). In the process, I wrote a verifier and found other problems as well: WARNING: snmp.app does not list snmpc.beam as a module WARNING: snmp.app does not list snmpc_lib.beam as a module WARNING: snmp.app does not list snmpc_mib_gram.beam as a module WARNING: snmp.app does not list snmpc_mib_to_hrl.beam as a module WARNING: snmp.app does not list snmpc_misc.beam as a module WARNING: snmp.app does not list snmpc_tok.beam as a module WARNING: asn1.app does not list asn1_db.beam as a module WARNING: asn1.app does not list asn1ct.beam as a module WARNING: asn1.app does not list asn1ct_check.beam as a module WARNING: asn1.app does not list asn1ct_constructed_ber.beam as a module WARNING: asn1.app does not list asn1ct_constructed_ber_bin_v2.beam as a module WARNING: asn1.app does not list asn1ct_constructed_per.beam as a module WARNING: asn1.app does not list asn1ct_gen.beam as a module WARNING: asn1.app does not list asn1ct_gen_ber.beam as a module WARNING: asn1.app does not list asn1ct_gen_ber_bin_v2.beam as a module WARNING: asn1.app does not list asn1ct_gen_per.beam as a module WARNING: asn1.app does not list asn1ct_gen_per_rt2ct.beam as a module WARNING: asn1.app does not list asn1ct_name.beam as a module WARNING: asn1.app does not list asn1ct_parser2.beam as a module WARNING: asn1.app does not list asn1ct_pretty_format.beam as a module WARNING: asn1.app does not list asn1ct_tok.beam as a module WARNING: asn1.app does not list asn1ct_value.beam as a module WARNING: sasl.app does not list si.beam as a module WARNING: sasl.app does not list si_sasl_supp.beam as a module Hopefully someone will find this useful. :) It would be great to see this included in the next release. D. From mikpe@REDACTED Mon Jul 27 23:55:51 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 27 Jul 2009 23:55:51 +0200 Subject: [erlang-questions] Missing HIPE modules in hipe.app In-Reply-To: References: Message-ID: <19054.8807.149918.977855@pilspetsen.it.uu.se> Dave Smith writes: > Hi all... > > As a part of constructing an erlang embedded node, I found that the > HIPE application is missing a number of modules from the .app file. > Consequently, systools doesn't include those modules when the HIPE > application is included in the release. I'm not sure if it's > intentional or not, but thought I'd submit a patch against hipe.app > (see attached). -ENOATTACHEDPATCH From dizzyd@REDACTED Tue Jul 28 00:11:06 2009 From: dizzyd@REDACTED (Dave Smith) Date: Mon, 27 Jul 2009 16:11:06 -0600 Subject: [erlang-questions] Missing HIPE modules in hipe.app In-Reply-To: <19054.8807.149918.977855@pilspetsen.it.uu.se> References: <19054.8807.149918.977855@pilspetsen.it.uu.se> Message-ID: Not sure what went wrong, here. Think I may not have waited long enough for gmail to upload the file (!!). Here is the patch again, this time against hipe.app.src, as suggested by my co-worker Jon Meredith. :) D. On Mon, Jul 27, 2009 at 3:55 PM, Mikael Pettersson wrote: > Dave Smith writes: > ?> Hi all... > ?> > ?> As a part of constructing an erlang embedded node, I found that the > ?> HIPE application is missing a number of modules from the .app file. > ?> Consequently, systools doesn't include those modules when the HIPE > ?> application is included in the release. I'm not sure if it's > ?> intentional or not, but thought I'd submit a patch against hipe.app > ?> (see attached). > > -ENOATTACHEDPATCH > From mikpe@REDACTED Tue Jul 28 00:31:17 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Tue, 28 Jul 2009 00:31:17 +0200 Subject: [erlang-questions] Missing HIPE modules in hipe.app In-Reply-To: References: <19054.8807.149918.977855@pilspetsen.it.uu.se> Message-ID: <19054.10933.736242.834672@pilspetsen.it.uu.se> Dave Smith writes: > Not sure what went wrong, here. Think I may not have waited long > enough for gmail to upload the file (!!). > > Here is the patch again, this time against hipe.app.src, as suggested > by my co-worker Jon Meredith. :) On first glance it looks correct but whitespace damaged (no tabs). I'll fix that up and apply it tomorrow. Thanks for reporting this. We obviously never use the app file so don't notice when it goes out of sync :-( /Mikael