From v@REDACTED Mon Aug 1 11:53:42 2011 From: v@REDACTED (=?UTF-8?B?0JLQsNC00LfRltC8INCX0LXQvdGM0LrQsA==?=) Date: Mon, 1 Aug 2011 12:53:42 +0300 Subject: [erlang-bugs] binary pattern matching fails with 32-bit float, if decimal representation of the number cannot be converted to binary exactly Message-ID: WHAT: binary pattern matching fails with 32-bit float, if decimal representation of the number cannot be converted to binary exactly EXAMPLE: following code fails: % "1.1" does not have exact binary representation > case <<1.1:32/float>> of <<1.1:32/float>> -> ok end. ** exception error: no case clause matching <<63,140,204,205>> > case <<63,140,204,205>> of <<1.1:32/float>> -> ok end. ** exception error: no case clause matching <<63,140,204,205>> although > case <<1.1:32/float>> of <<63,140,204,205>> -> ok end. ok % "1.5" has exact binary representation > case <<1.5:32/float>> of <<1.5:32/float>> -> ok end. ok % 64-bit floats work well > case <<1.1:64/float>> of <<1.1:64/float>> -> ok end. ok -- ? ???????, ?????? ?????? v@REDACTED vadzim@REDACTED +375.29.407.27.17 From ulf.wiger@REDACTED Mon Aug 1 12:06:59 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 1 Aug 2011 12:06:59 +0200 Subject: [erlang-bugs] binary pattern matching fails with 32-bit float, if decimal representation of the number cannot be converted to binary exactly In-Reply-To: References: Message-ID: <9DC81A99-8DB8-4698-9C8D-273210631708@erlang-solutions.com> Compiling to BEAM ASM illustrates why: >> case <<1.1:32/float>> of <<1.1:32/float>> -> ok end. > ** exception error: no case clause matching <<63,140,204,205>> {function, f, 0, 2}. {label,1}. {func_info,{atom,bin_match},{atom,f},0}. {label,2}. {move,{literal,<<63,140,204,205>>},{x,0}}. {test,bs_start_match2,{f,3},1,[{x,0},0],{x,1}}. {test,bs_get_float2, {f,3}, 2, [{x,1}, {integer,32}, 1, {field_flags,[{anno,[6,{file,"./bin_match.erl"}]},unsigned,big]}], {x,2}}. {test,is_eq_exact,{f,3},[{x,2},{float,1.1}]}. {test,bs_test_tail2,{f,3},[{x,1},0]}. {move,{atom,ok},{x,0}}. return. {label,3}. {case_end,{x,0}}. The constructor pattern is evaluated at compile-time, so the binary appears in the ASM. The match pattern uses the bit syntax operators to extract a float, and then checks the result (now using native float representation) to the hard-coded float 1.1. Whether or not this is desirable is another discussion, but you can work around it by constructing the binaries and comparing them. It's not that the construction itself is non-deterministic. BR, Ulf W On 1 Aug 2011, at 11:53, ?????? ?????? wrote: > WHAT: > binary pattern matching fails with 32-bit float, if decimal > representation of the number cannot be converted to binary exactly > > EXAMPLE: > following code fails: > > % "1.1" does not have exact binary representation >> case <<1.1:32/float>> of <<1.1:32/float>> -> ok end. > ** exception error: no case clause matching <<63,140,204,205>> > >> case <<63,140,204,205>> of <<1.1:32/float>> -> ok end. > ** exception error: no case clause matching <<63,140,204,205>> > > although > >> case <<1.1:32/float>> of <<63,140,204,205>> -> ok end. > ok > > % "1.5" has exact binary representation >> case <<1.5:32/float>> of <<1.5:32/float>> -> ok end. > ok > > % 64-bit floats work well >> case <<1.1:64/float>> of <<1.1:64/float>> -> ok end. > ok > > -- > ? ???????, ?????? ?????? > v@REDACTED > vadzim@REDACTED > +375.29.407.27.17 > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From v@REDACTED Mon Aug 1 12:09:39 2011 From: v@REDACTED (=?UTF-8?B?0JLQsNC00LfRltC8INCX0LXQvdGM0LrQsA==?=) Date: Mon, 1 Aug 2011 13:09:39 +0300 Subject: [erlang-bugs] binary pattern matching fails with 32-bit float, if decimal representation of the number cannot be converted to binary exactly Message-ID: Version: Erlang 5.8.4/OTP R14B03 Sorry. -- ? ???????, ?????? ?????? v@REDACTED vadzim@REDACTED +375.29.407.27.17 From lars@REDACTED Tue Aug 9 15:03:08 2011 From: lars@REDACTED (Lars Thorsen) Date: Tue, 9 Aug 2011 15:03:08 +0200 Subject: [erlang-bugs] Bug when streaming input to xmerl_scan In-Reply-To: <25564-1311793941-889957@sneakemail.com> References: <25564-1311793941-889957@sneakemail.com> Message-ID: <4E41300C.4040101@erix.ericsson.se> Thanks Simon, your fix will be applied in R14B04. Regards Lars Erlang/OTP, Ericsson AB On 07/27/2011 09:12 PM, Simon Cornish wrote: > Consider the following trivial XML: > > > blah > > If this is being fed to xmerl_scan:string via a continuation_fun and > the current input runs out at the end of an attribute value (in this > example, the 2nd " character on the item line) then it will crash. > This is demonstrated in the small attached module. > One possible fix that has been tested is also attached. > > Regards, > Simon > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From Anders.Ramsell@REDACTED Fri Aug 12 14:45:15 2011 From: Anders.Ramsell@REDACTED (Anders.Ramsell@REDACTED) Date: Fri, 12 Aug 2011 14:45:15 +0200 Subject: [erlang-bugs] filename:join breaks Windows UNC paths In-Reply-To: <1311096453808-3678716.post@n4.nabble.com> Message-ID: <4B5A1820C84D9E4C9B6A281B2C1DA64E130049B4BF@EXCCR02TSBRZ2.tcad.telia.se> > -----Original Message----- > Sorry to resurrect an old post, but this just bit me and cost > me a day or > two. Evgeny's patch works and applies to R14B01 and R14B03, > though the line > numbers are now a bit off. I've edited the patch below. > > Not sure what the proper convention is, but I'd like to vote > for this being included in a future release if possible. > The current assumption that all paths on win32 start with > a drive letter is no longer valid, especially if > extended-path name notation is being used > (\\?\very\long\path). This is an increasingly common need. I'd like to add a vote for having this problem fixed since we have also been bit by this. It also appears that some "pathfunctions" like file:get_cwd/0 already support the "dubble-slash" syntax. The following shell interaction shows the problem we've had: 1> {ok, Path} = file:get_cwd(). {ok, "//host/share"} 2> filename:join(Path, "file.txt"). "/host/share/file.txt" Notice that the dubble-slash returned by file:get_cwd/0 gets lost in the call to filename:join/2. /Anders Ramsell From robert.newson@REDACTED Fri Aug 12 23:50:06 2011 From: robert.newson@REDACTED (Robert Newson) Date: Fri, 12 Aug 2011 22:50:06 +0100 Subject: [erlang-bugs] Repeatable output from crypto:rand_uniform with negative Low value Message-ID: Hi, I've noticed that repeated calls to crypto:rand_uniform return the same values if Low is negative and High is (approximately) equal to -Low, and the answer is also outside of the requested range. e.g,; 7> crypto:rand_uniform(-10000,10000). 65536 8> crypto:rand_uniform(-10000,10000). 65536 9> crypto:rand_uniform(-10000,10000). 65536 This is with R14B03. Regards, B. From dave@REDACTED Sun Aug 14 05:02:04 2011 From: dave@REDACTED (Dave Cottlehuber) Date: Sun, 14 Aug 2011 15:02:04 +1200 Subject: [erlang-bugs] filename:join breaks Windows UNC paths In-Reply-To: <1311096453808-3678716.post@n4.nabble.com> References: <201007180913.40475.khirin@zahav.net.il> <1311096453808-3678716.post@n4.nabble.com> Message-ID: On 20 July 2011 05:27, wohali wrote: > Sorry to resurrect an old post, but this just bit me and cost me a day or > two. Evgeny's patch works and applies to R14B01 and R14B03, though the line > numbers are now a bit off. I've edited the patch below. > > Not sure what the proper convention is, but I'd like to vote for this being > included in a future release if possible. The current assumption that all > paths on win32 start with a drive letter is no longer valid, especially if > extended-path name notation is being used (\\?\very\long\path). This is an > increasingly common need. > > ------------------- patch -------------------------------- > diff --git a/lib/stdlib/src/filename.erl b/lib/stdlib/src/filename.erl > index 01c06e4..8da54ef 100644 > --- a/lib/stdlib/src/filename.erl > +++ b/lib/stdlib/src/filename.erl > @@ -426,6 +426,10 @@ join(Name1, Name2) when is_atom(Name2) -> > ?%% It is the responsibility of the caller to ensure that RelativeName > ?%% is relative. > > +join1([$/, $/ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, > RelativeName, [], win32)]; > +join1([$/, $\\ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, > RelativeName, [], win32)]; > +join1([$\\, $/ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, > RelativeName, [], win32)]; > +join1([$\\, $\\ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, > RelativeName, [], win32)]; > ?join1([UcLetter, $:|Rest], RelativeName, [], win32) > ?when is_integer(UcLetter), UcLetter >= $A, UcLetter =< $Z -> > ? ? join1(Rest, RelativeName, [$:, UcLetter+$a-$A], win32); > ------------------- patch -------------------------------- > > > -- > View this message in context: http://erlang.2086793.n4.nabble.com/filename-join-breaks-Windows-UNC-paths-tp2292894p3678716.html > Sent from the Erlang Bugs mailing list archive at Nabble.com. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > Improve win32 UNC path support in stdlib/filename.erl Thanks Wohali & Evgeny. NB cross-posted to erlang-bugs & erlang-patches. https://github.com/dch/otp/compare/win32-unc-path-support git fetch git://github.com/dch/otp.git win32-unc-path-support Cheers, Dave From fdmanana@REDACTED Mon Aug 15 00:18:19 2011 From: fdmanana@REDACTED (Filipe David Manana) Date: Sun, 14 Aug 2011 15:18:19 -0700 Subject: [erlang-bugs] SIGBUS on init:restart() Message-ID: If I compile OTP R14B03 (also tried R14B01, and got same issue) for 64bits mode in Mac OS X Lion, when calling init:restart() in my application I get a SIGBUS signal, which causes the VM to terminate (it happens very often, but not always) with the error message "Bus error: 10". Here's some information from gdb which might be useful: http://friendpaste.com/AL9GKX2pNdyb3NIEYWxcR Ignoring the SIGBUS signal prevents the crash, but this is likely masking some bug: diff --git a/erts/emulator/sys/unix/sys.c b/erts/emulator/sys/unix/sys.c index bafbbb0..86c3f57 100644 --- a/erts/emulator/sys/unix/sys.c +++ b/erts/emulator/sys/unix/sys.c @@ -3031,6 +3031,9 @@ erts_sys_main_thread(void) fd_set readfds; int res; + signal(SIGPIPE, SIG_IGN); + signal(SIGBUS, SIG_IGN); + FD_ZERO(&readfds); FD_SET(erts_darwin_main_thread_pipe[0], &readfds); res = select(erts_darwin_main_thread_pipe[0] + 1, &readfds, NULL, NULL, NULL); OTP was configured like this: $ CFLAGS="-O0" ./configure --enable-darwin-64bit --prefix=/opt/r14b03 Without the --enable-darwin-64bit option, the issue doesn't happen. Is this a known issue or can it be application-specific? How to debug it further? This issue doesn't seem to happen on Linux and Mac OS X snowleopard systems. thanks -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From fdmanana@REDACTED Mon Aug 15 02:58:13 2011 From: fdmanana@REDACTED (Filipe David Manana) Date: Sun, 14 Aug 2011 17:58:13 -0700 Subject: [erlang-bugs] SIGBUS on init:restart() In-Reply-To: References: Message-ID: Found out the issue. It turned out to be a bad cast in linked in driver from CouchDB: diff --git a/src/couchdb/priv/icu_driver/couch_icu_driver.c b/src/couchdb/priv/icu_driver/couch_icu_driver.c index 9f20e99..edfd84a 100644 --- a/src/couchdb/priv/icu_driver/couch_icu_driver.c +++ b/src/couchdb/priv/icu_driver/couch_icu_driver.c @@ -45,7 +45,7 @@ static void couch_drv_stop(ErlDrvData data) if (pData->collNoCase) { ucol_close(pData->collNoCase); } - driver_free((char*)pData); + driver_free((void*)pData); } static ErlDrvData couch_drv_start(ErlDrvPort port, char *buff) On Sun, Aug 14, 2011 at 3:18 PM, Filipe David Manana wrote: > If I compile OTP R14B03 (also tried R14B01, and got same issue) for > 64bits mode in Mac OS X Lion, when calling init:restart() in my > application I get a SIGBUS signal, which causes the VM to terminate > (it happens very often, but not always) with the error message "Bus > error: 10". > > Here's some information from gdb which might be useful: > > http://friendpaste.com/AL9GKX2pNdyb3NIEYWxcR > > Ignoring the SIGBUS signal prevents the crash, but this is likely > masking some bug: > > diff --git a/erts/emulator/sys/unix/sys.c b/erts/emulator/sys/unix/sys.c > index bafbbb0..86c3f57 100644 > --- a/erts/emulator/sys/unix/sys.c > +++ b/erts/emulator/sys/unix/sys.c > @@ -3031,6 +3031,9 @@ erts_sys_main_thread(void) > ? ? ? ?fd_set readfds; > ? ? ? ?int res; > > + ? ?signal(SIGPIPE, SIG_IGN); > + ? ?signal(SIGBUS, SIG_IGN); > + > ? ? ? ?FD_ZERO(&readfds); > ? ? ? ?FD_SET(erts_darwin_main_thread_pipe[0], &readfds); > ? ? ? ?res = select(erts_darwin_main_thread_pipe[0] + 1, &readfds, > NULL, NULL, NULL); > > > OTP was configured like this: > > $ CFLAGS="-O0" ./configure --enable-darwin-64bit --prefix=/opt/r14b03 > > Without the --enable-darwin-64bit option, the issue doesn't happen. > > Is this a known issue or can it be application-specific? How to debug > it further? > > This issue doesn't seem to happen on Linux and Mac OS X snowleopard systems. > > thanks > > > -- > Filipe David Manana, > fdmanana@REDACTED, fdmanana@REDACTED > > "Reasonable men adapt themselves to the world. > ?Unreasonable men adapt the world to themselves. > ?That's why all progress depends on unreasonable men." > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From baggett.patrick@REDACTED Mon Aug 15 03:45:13 2011 From: baggett.patrick@REDACTED (Patrick Baggett) Date: Sun, 14 Aug 2011 20:45:13 -0500 Subject: [erlang-bugs] SIGBUS on init:restart() In-Reply-To: References: Message-ID: A typecast? That shouldn't affect code generation like that. Are you sure you didn't just need to do a clean build or something? On Sun, Aug 14, 2011 at 7:58 PM, Filipe David Manana wrote: > Found out the issue. It turned out to be a bad cast in linked in > driver from CouchDB: > > diff --git a/src/couchdb/priv/icu_driver/couch_icu_driver.c > b/src/couchdb/priv/icu_driver/couch_icu_driver.c > index 9f20e99..edfd84a 100644 > --- a/src/couchdb/priv/icu_driver/couch_icu_driver.c > +++ b/src/couchdb/priv/icu_driver/couch_icu_driver.c > @@ -45,7 +45,7 @@ static void couch_drv_stop(ErlDrvData data) > if (pData->collNoCase) { > ucol_close(pData->collNoCase); > } > - driver_free((char*)pData); > + driver_free((void*)pData); > } > > static ErlDrvData couch_drv_start(ErlDrvPort port, char *buff) > > > > On Sun, Aug 14, 2011 at 3:18 PM, Filipe David Manana > wrote: > > If I compile OTP R14B03 (also tried R14B01, and got same issue) for > > 64bits mode in Mac OS X Lion, when calling init:restart() in my > > application I get a SIGBUS signal, which causes the VM to terminate > > (it happens very often, but not always) with the error message "Bus > > error: 10". > > > > Here's some information from gdb which might be useful: > > > > http://friendpaste.com/AL9GKX2pNdyb3NIEYWxcR > > > > Ignoring the SIGBUS signal prevents the crash, but this is likely > > masking some bug: > > > > diff --git a/erts/emulator/sys/unix/sys.c b/erts/emulator/sys/unix/sys.c > > index bafbbb0..86c3f57 100644 > > --- a/erts/emulator/sys/unix/sys.c > > +++ b/erts/emulator/sys/unix/sys.c > > @@ -3031,6 +3031,9 @@ erts_sys_main_thread(void) > > fd_set readfds; > > int res; > > > > + signal(SIGPIPE, SIG_IGN); > > + signal(SIGBUS, SIG_IGN); > > + > > FD_ZERO(&readfds); > > FD_SET(erts_darwin_main_thread_pipe[0], &readfds); > > res = select(erts_darwin_main_thread_pipe[0] + 1, &readfds, > > NULL, NULL, NULL); > > > > > > OTP was configured like this: > > > > $ CFLAGS="-O0" ./configure --enable-darwin-64bit --prefix=/opt/r14b03 > > > > Without the --enable-darwin-64bit option, the issue doesn't happen. > > > > Is this a known issue or can it be application-specific? How to debug > > it further? > > > > This issue doesn't seem to happen on Linux and Mac OS X snowleopard > systems. > > > > thanks > > > > > > -- > > Filipe David Manana, > > fdmanana@REDACTED, fdmanana@REDACTED > > > > "Reasonable men adapt themselves to the world. > > Unreasonable men adapt the world to themselves. > > That's why all progress depends on unreasonable men." > > > > > > -- > Filipe David Manana, > fdmanana@REDACTED, fdmanana@REDACTED > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdmanana@REDACTED Mon Aug 15 04:18:39 2011 From: fdmanana@REDACTED (Filipe David Manana) Date: Sun, 14 Aug 2011 19:18:39 -0700 Subject: [erlang-bugs] SIGBUS on init:restart() In-Reply-To: References: Message-ID: On Sun, Aug 14, 2011 at 6:45 PM, Patrick Baggett wrote: > A typecast? That shouldn't affect code generation like that. Are you sure > you didn't just need to do a clean build or something? Yep. I did clean builds, by wiping out the directory and extracting the source tarballs, both with r14b03 and r14b01. Also tried with a GCC version without LLVM (the default one in my environment has LLVM, while the gcc-4.2 doesn't). With that cast correction, I no longer get the sigbus signal. I'm surprised too. > > On Sun, Aug 14, 2011 at 7:58 PM, Filipe David Manana > wrote: >> >> Found out the issue. It turned out to be a bad cast in linked in >> driver from CouchDB: >> >> diff --git a/src/couchdb/priv/icu_driver/couch_icu_driver.c >> b/src/couchdb/priv/icu_driver/couch_icu_driver.c >> index 9f20e99..edfd84a 100644 >> --- a/src/couchdb/priv/icu_driver/couch_icu_driver.c >> +++ b/src/couchdb/priv/icu_driver/couch_icu_driver.c >> @@ -45,7 +45,7 @@ static void couch_drv_stop(ErlDrvData data) >> ? ? if (pData->collNoCase) { >> ? ? ? ? ucol_close(pData->collNoCase); >> ? ? } >> - ? ?driver_free((char*)pData); >> + ? ?driver_free((void*)pData); >> ?} >> >> ?static ErlDrvData couch_drv_start(ErlDrvPort port, char *buff) >> >> >> >> On Sun, Aug 14, 2011 at 3:18 PM, Filipe David Manana >> wrote: >> > If I compile OTP R14B03 (also tried R14B01, and got same issue) for >> > 64bits mode in Mac OS X Lion, when calling init:restart() in my >> > application I get a SIGBUS signal, which causes the VM to terminate >> > (it happens very often, but not always) with the error message "Bus >> > error: 10". >> > >> > Here's some information from gdb which might be useful: >> > >> > http://friendpaste.com/AL9GKX2pNdyb3NIEYWxcR >> > >> > Ignoring the SIGBUS signal prevents the crash, but this is likely >> > masking some bug: >> > >> > diff --git a/erts/emulator/sys/unix/sys.c b/erts/emulator/sys/unix/sys.c >> > index bafbbb0..86c3f57 100644 >> > --- a/erts/emulator/sys/unix/sys.c >> > +++ b/erts/emulator/sys/unix/sys.c >> > @@ -3031,6 +3031,9 @@ erts_sys_main_thread(void) >> > ? ? ? ?fd_set readfds; >> > ? ? ? ?int res; >> > >> > + ? ?signal(SIGPIPE, SIG_IGN); >> > + ? ?signal(SIGBUS, SIG_IGN); >> > + >> > ? ? ? ?FD_ZERO(&readfds); >> > ? ? ? ?FD_SET(erts_darwin_main_thread_pipe[0], &readfds); >> > ? ? ? ?res = select(erts_darwin_main_thread_pipe[0] + 1, &readfds, >> > NULL, NULL, NULL); >> > >> > >> > OTP was configured like this: >> > >> > $ CFLAGS="-O0" ./configure --enable-darwin-64bit --prefix=/opt/r14b03 >> > >> > Without the --enable-darwin-64bit option, the issue doesn't happen. >> > >> > Is this a known issue or can it be application-specific? How to debug >> > it further? >> > >> > This issue doesn't seem to happen on Linux and Mac OS X snowleopard >> > systems. >> > >> > thanks >> > >> > >> > -- >> > Filipe David Manana, >> > fdmanana@REDACTED, fdmanana@REDACTED >> > >> > "Reasonable men adapt themselves to the world. >> > ?Unreasonable men adapt the world to themselves. >> > ?That's why all progress depends on unreasonable men." >> > >> >> >> >> -- >> Filipe David Manana, >> fdmanana@REDACTED, fdmanana@REDACTED >> >> "Reasonable men adapt themselves to the world. >> ?Unreasonable men adapt the world to themselves. >> ?That's why all progress depends on unreasonable men." >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -- Filipe David Manana, fdmanana@REDACTED, fdmanana@REDACTED "Reasonable men adapt themselves to the world. ?Unreasonable men adapt the world to themselves. ?That's why all progress depends on unreasonable men." From ingela@REDACTED Mon Aug 15 12:00:22 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 15 Aug 2011 12:00:22 +0200 Subject: [erlang-bugs] odbc module lacks in a mode after executing stored procedures In-Reply-To: <1311697790265-3696283.post@n4.nabble.com> References: <1311697790265-3696283.post@n4.nabble.com> Message-ID: <4E48EE36.4010701@erix.ericsson.se> Hi! It looks like the contributer of input/output parameter-handling forgot to clear the state which would explain your problem. Could you test if the following patch solves your problem? diff --git a/lib/odbc/c_src/odbcserver.c b/lib/odbc/c_src/odbcserver.c index 11e311d..6ef3988 100644 --- a/lib/odbc/c_src/odbcserver.c +++ b/lib/odbc/c_src/odbcserver.c @@ -2011,6 +2011,7 @@ static void clean_state(db_state *state) free_column_buffer(&(columns(state)), nr_of_columns(state)); columns(state) = NULL; nr_of_columns(state) = 0; + out_params(state) = FALSE; } Regards Ingela Erlang/OTP team - Ericsson AB cymoon wrote: > I am using Erlang together with an Oracle 11g database on a windows machine. > When I execute a stored procedure using param_query, the odbc module > executes further statements as if they where also stored procedures. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%% > odbc:start(permanent), > {ok, Ref} = odbc:connect(ConnectStr, Options), > > Result1 =odbc:param_query(Ref, "select ? from dual",[{ sql_integer,[1]}]), > io:format("~p~n",[Result1]), > % returns: {selected,[":1"],[{1.0}]} > > Result2 =odbc:param_query(Ref, "{ ? = call NVL (2,2) > }",[{sql_integer,out,[1]}]), > io:format("~p~n",[Result2]), > % returns: {executed,1,[{2}]} > > Result3 =odbc:param_query(Ref, "select ? from dual",[{ sql_integer,[3]}]), > io:format("~p~n",[Result3]), > % returns: {executed,0,[{}]} but should return {selected,[":1"],[{3.0}]} > %%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > To make sure that it is a bug in erlang, I wrote the same test in C#. It > works as expected: > > ///////////////////////////////////////// > OdbcConnection con = new OdbcConnection(); > con.ConnectionString = "DSN=flexdoc_dev;UID=nn2;PWD=nn2"; > con.Open(); OdbcCommand cmd; OdbcDataReader dr; > > cmd = new OdbcCommand("SELECT ? val FROM dual", con); > cmd.Parameters.AddWithValue("", 1); > dr = cmd.ExecuteReader(); dr.Read(); > Console.WriteLine(dr["val"].ToString()); > // returns 1 > > cmd = new OdbcCommand("{ ? = CALL NVL(2,2) }", con); > cmd.CommandType = CommandType.StoredProcedure; > OdbcParameter parameter = cmd.Parameters.Add("returnVal", OdbcType.Int); > parameter.Direction = ParameterDirection.ReturnValue; > dr = cmd.ExecuteReader(); dr.Close(); > Console.WriteLine(cmd.Parameters["returnVal"].Value); > // returns 2 > > cmd = new OdbcCommand("SELECT ? val FROM dual", con); > cmd.Parameters.AddWithValue("", 3); > dr = cmd.ExecuteReader(); dr.Read(); > Console.WriteLine(dr["val"].ToString()); > // returns 3 > ///////////////////////////////////////// > > > > -- > View this message in context: http://erlang.2086793.n4.nabble.com/odbc-module-lacks-in-a-mode-after-executing-stored-procedures-tp3696283p3696283.html > Sent from the Erlang Bugs mailing list archive at Nabble.com. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > From ulf.wiger@REDACTED Tue Aug 16 18:56:24 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 16 Aug 2011 18:56:24 +0200 Subject: [erlang-bugs] buggy comment in calendar.erl Message-ID: My eye just happened to catch on this: %% now_to_universal_time(Now) %% now_to_datetime(Now) %% %% Convert from now() to UTC. %% %% Args: Now = now(); now() = {MegaSec, Sec, MilliSec}, MegaSec = Sec %% = MilliSec = integer() The format of now() is {MegaSec, Sec, MicroSec}, not {MegaSec, Sec, MilliSec}. It's just a commenting bug, since the function freely ignores the third element. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From henrik@REDACTED Wed Aug 17 15:57:21 2011 From: henrik@REDACTED (Henrik Nord) Date: Wed, 17 Aug 2011 15:57:21 +0200 Subject: [erlang-bugs] [erlang-patches] filename:join breaks Windows UNC paths In-Reply-To: References: <201007180913.40475.khirin@zahav.net.il> <1311096453808-3678716.post@n4.nabble.com> Message-ID: <4E4BC8C1.2060304@erlang.org> On 08/14/2011 05:02 AM, Dave Cottlehuber wrote: > On 20 July 2011 05:27, wohali wrote: >> Sorry to resurrect an old post, but this just bit me and cost me a day or >> two. Evgeny's patch works and applies to R14B01 and R14B03, though the line >> numbers are now a bit off. I've edited the patch below. >> >> Not sure what the proper convention is, but I'd like to vote for this being >> included in a future release if possible. The current assumption that all >> paths on win32 start with a drive letter is no longer valid, especially if >> extended-path name notation is being used (\\?\very\long\path). This is an >> increasingly common need. >> >> ------------------- patch -------------------------------- >> diff --git a/lib/stdlib/src/filename.erl b/lib/stdlib/src/filename.erl >> index 01c06e4..8da54ef 100644 >> --- a/lib/stdlib/src/filename.erl >> +++ b/lib/stdlib/src/filename.erl >> @@ -426,6 +426,10 @@ join(Name1, Name2) when is_atom(Name2) -> >> %% It is the responsibility of the caller to ensure that RelativeName >> %% is relative. >> >> +join1([$/, $/ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, >> RelativeName, [], win32)]; >> +join1([$/, $\\ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, >> RelativeName, [], win32)]; >> +join1([$\\, $/ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, >> RelativeName, [], win32)]; >> +join1([$\\, $\\ | Rest], RelativeName, [], win32) -> [$/, $/ | join1(Rest, >> RelativeName, [], win32)]; >> join1([UcLetter, $:|Rest], RelativeName, [], win32) >> when is_integer(UcLetter), UcLetter>= $A, UcLetter =< $Z -> >> join1(Rest, RelativeName, [$:, UcLetter+$a-$A], win32); >> ------------------- patch -------------------------------- >> >> >> -- >> View this message in context: http://erlang.2086793.n4.nabble.com/filename-join-breaks-Windows-UNC-paths-tp2292894p3678716.html >> Sent from the Erlang Bugs mailing list archive at Nabble.com. >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > Improve win32 UNC path support in stdlib/filename.erl > Thanks Wohali& Evgeny. > NB cross-posted to erlang-bugs& erlang-patches. > > https://github.com/dch/otp/compare/win32-unc-path-support > > git fetch git://github.com/dch/otp.git win32-unc-path-support > > Cheers, > Dave > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://erlang.org/mailman/listinfo/erlang-patches Hello We have yet to decide on a more general approach to these issues, and as such we may or may not choose to include this specific fix. It will have to wait until then. Thank you for your contribution. -- /Henrik Nord Erlang/OTP From g@REDACTED Thu Aug 18 01:06:53 2011 From: g@REDACTED (Garrett Smith) Date: Wed, 17 Aug 2011 18:06:53 -0500 Subject: [erlang-bugs] yecc example bug Message-ID: In http://www.erlang.org/doc/man/yecc.html The text (it occurs in two examples): E -> E '+' E : ['$1', '$2', '$3']. E -> E '*' E : ['$1', '$2', '$3']. Should be: E -> E '+' E : ['$2', '$1', '$3']. E -> E '*' E : ['$2', '$1', '$3']. The point of the examples is "parsing infix arithmetic expressions into prefix notation". Without reordering the triplet, the parse is a no-op. Garrett From essen@REDACTED Tue Aug 23 12:49:54 2011 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Tue, 23 Aug 2011 12:49:54 +0200 Subject: [erlang-bugs] erlang:decode_packet/3 issues Message-ID: <4E5385D2.7010308@dev-extend.eu> Hello, Sorry if it has already been reported but I'd like to point to two issues in erlang:decode_packet/3: one is a bug, the other just an annoying limitation. There is a bug in erlang:decode_packet/3 that happens when we have an header name with a - following another. If we have an even number of -, then the following character is lowercase, otherwise it's uppercase: 1> erlang:decode_packet(httph, <<"test-test: test\r\n\r\n">>, []). {ok,{http_header,0,"Test-Test",undefined,"test"},<<"\r\n">>} 2> erlang:decode_packet(httph, <<"test--test: test\r\n\r\n">>, []). {ok,{http_header,0,"Test--test",undefined,"test"}, <<"\r\n">>} 3> erlang:decode_packet(httph, <<"test---test: test\r\n\r\n">>, []). {ok,{http_header,0,"Test---Test",undefined,"test"}, <<"\r\n">>} The other issue comes when we have header names bigger than 20 characters in length. It's a bit low for some header names, for example Sec-Websocket-Version: 4> erlang:decode_packet(httph, <<"sec-websocket-version: 8\r\n\r\n">>, []). {ok,{http_header,0,"sec-websocket-version",undefined,"8"}, <<"\r\n">>} 5> erlang:decode_packet(httph, <<"sec-websocket-versio: 8\r\n\r\n">>, []). {ok,{http_header,0,"Sec-Websocket-Versio",undefined,"8"}, <<"\r\n">>} It would be appreciated if that number could be increased at least a little or be made configurable. Otherwise we end up having to write the same code in our applications to handle the longer header names. -- Lo?c Hoguin Dev:Extend From anthony.shipman@REDACTED Thu Aug 25 06:18:36 2011 From: anthony.shipman@REDACTED (anthony.shipman@REDACTED) Date: Thu, 25 Aug 2011 14:18:36 +1000 Subject: [erlang-bugs] escript results in disk_log space leak in R12B4 Message-ID: <201108251418.36068.anthony.shipman@symstream.com> I have a simple escript that dumps the contents of a disk_log file. It uses disk_log:chunk() to iterate through the records and prints them. The memory usage climbs dramatically on a large file. The loop in the program is readLog(Cont) -> case disk_log:chunk(log, Cont) of eof -> ok; {error, Reason} -> error("when reading the log: ~p", [Reason]), ok; {Cont2, Terms} -> dumpTerms(Terms), %util:debug("Cont2 ~p\n", [Cont2]), readLog(Cont2); {Cont2, Terms, BadBytes} -> dumpTerms(Terms), warning("~p bad bytes were skipped", [BadBytes]), readLog(Cont2) end. The Cont term just contains terms like Cont2 = {continuation,<0.34.0>,65408,271} I've put in some statistics tracking code. For these tests dumpTerms() is a dummy function. Early in the run I have <0.29.0>: [{registered_name,[]}, {initial_call,{erlang,apply,2}}, {current_function,{disk_log,bins2terms,2}}, {memory,2057284}, {heap_size,514229}, {stack_size,66}, {total_heap_size,514229}, {binary,[{3078463584,65536,287}, {3078463584,65536,287}, ....... 286 of these lines {3078463584,65536,287}, {3078463584,65536,287}]}, {dictionary,[]}, {garbage_collection,[{fullsweep_after,1},{minor_gcs,0}]}] <0.34.0>: [{registered_name,[]}, {initial_call,{proc_lib,init_p,5}}, {current_function,{disk_log,loop,1}}, {memory,17212}, {heap_size,4181}, {stack_size,7}, {total_heap_size,4181}, {binary,[{3078463584,65536,287}]}, {dictionary, [{log, {log,ok,log,none,0,"../logs/diag_archive_2011-08-05.log", [{<0.29.0>,false}], halt,internal,halt_int,none,read_only,infinity, {halt, {cache, {file_descriptor,prim_file,{#Port<0.101>,8}}, 0,[]}, 709715947,infinity}, undefined}}, {'$ancestors', [disk_log_sup,kernel_safe_sup,kernel_sup,<0.8.0>]}, {'$initial_call',{disk_log,init,[<0.32.0>,<0.33.0>]}}]}, {garbage_collection,[{fullsweep_after,1},{minor_gcs,0}]}] This makes sense. The program's loop has sliced a 64K binary from the disk_log server into many records. A little later the address of the binary is different. This also makes sense. A GC occurred to clean out the old binaries and only the most recently read binary appeared in the stats. But much later I have <0.29.0>: [{registered_name,[]}, {initial_call,{erlang,apply,2}}, {current_function,undefined}, {memory,154539648}, {heap_size,8024355}, {stack_size,1970}, {total_heap_size,38634820}, {binary,[{2988208416,65536,310}, {2988208416,65536,310}, ............... {3083842192,65536,254}, ............... {2987487256,65536,283}, lots of entries from 22 different binaries ............... {dictionary,[]}, {garbage_collection,[{fullsweep_after,1},{minor_gcs,1}]}] <0.34.0>: [{registered_name,[]}, {initial_call,{proc_lib,init_p,5}}, {current_function,{disk_log,loop,1}}, {memory,17212}, {heap_size,4181}, {stack_size,7}, {total_heap_size,4181}, {binary,[{2988995136,65536,319}]}, {dictionary, [{log, {log,ok,log,none,0,"../logs/diag_archive_2011-08-05.log", [{<0.29.0>,false}], halt,internal,halt_int,none,read_only,infinity, {halt, {cache, {file_descriptor,prim_file,{#Port<0.101>,8}}, 0,[]}, 709715947,infinity}, undefined}}, {'$ancestors', [disk_log_sup,kernel_safe_sup,kernel_sup,<0.8.0>]}, {'$initial_call',{disk_log,init,[<0.32.0>,<0.33.0>]}}]}, {garbage_collection,[{fullsweep_after,1},{minor_gcs,0}]}] The memory usage of the readLog() process has gone up to 150MB and the stack is growing. I thought that there was some serious problem with the GC until I finally remembered to try -mode(compile) and the problem went away. This is a trap in the behaviour of the escript interpreter. Something in the interpreter is not properly tail-call optimized. -- Anthony Shipman | What most people think about Anthony.Shipman@REDACTED | most things is mostly wrong. From pguyot@REDACTED Thu Aug 25 12:55:33 2011 From: pguyot@REDACTED (Paul Guyot) Date: Thu, 25 Aug 2011 12:55:33 +0200 Subject: [erlang-bugs] escript results in disk_log space leak in R12B In-Reply-To: References: Message-ID: <8AA63AAF-5565-4587-93C7-378A2C86BDB2@kallisys.net> Le 25 ao?t 2011 ? 12:00, erlang-bugs-request@REDACTED a ?crit : > I thought that there was some serious problem with the GC until I finally > remembered to try -mode(compile) and the problem went away. This is a trap in > the behaviour of the escript interpreter. Something in the interpreter is not > properly tail-call optimized. This bug was fixed in R13B01. From http://www.erlang.org/download/otp_src_R13B01.readme : > OTP-7933 Interpreted escripts are now tail recursive. Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Paris From kenji.rikitake@REDACTED Thu Aug 25 18:37:27 2011 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Fri, 26 Aug 2011 01:37:27 +0900 Subject: [erlang-bugs] a crypto function call crashes VM Message-ID: <20110825163727.GA6382@k2r.org> Enter the following code to erl shell: crypto:sha_update( list_to_binary(lists:reverse(binary_to_list(crypto:sha_init()))), "hello"). Segmentation fault occurs and VM crashed with the core dump. This is originally reported at https://twitter.com/#!/szktty/status/106761685284564992 by Tetsuya Suzuki (Twitter: @szktty) (Tweet in Japanese but the code is the same as shown here) Verified on R14B03 running on FreeBSD 8.2-RELEASE x86 and R14B03 running on RHEL v4 x86_64 for Kyoto University Supercomputer Thin Cluster. Kenji Rikitake From ess@REDACTED Thu Aug 25 18:58:21 2011 From: ess@REDACTED (=?iso-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Thu, 25 Aug 2011 18:58:21 +0200 Subject: [erlang-bugs] a crypto function call crashes VM In-Reply-To: <20110825163727.GA6382@k2r.org> References: <20110825163727.GA6382@k2r.org> Message-ID: Simpler version: crypto:sha_update(list_to_binary(lists:seq(1,96)). Boundary: 6> crypto:sha_update(list_to_binary([0 || _ <- lists:seq(1,96)]), "x"). <<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,0,0,0,0,0,0,0, 120,...>> 7> crypto:sha_update(list_to_binary([1 || _ <- lists:seq(1,96)]), "x"). Segmentation fault (Probably part of the binary is interpreted as a pointer, except when NULL.) ________________________________________ Fra: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] På vegne af Kenji Rikitake [kenji.rikitake@REDACTED] Sendt: 25. august 2011 18:37 Til: erlang-bugs@REDACTED Emne: [erlang-bugs] a crypto function call crashes VM Enter the following code to erl shell: crypto:sha_update( list_to_binary(lists:reverse(binary_to_list(crypto:sha_init()))), "hello"). Segmentation fault occurs and VM crashed with the core dump. This is originally reported at https://twitter.com/#!/szktty/status/106761685284564992 by Tetsuya Suzuki (Twitter: @szktty) (Tweet in Japanese but the code is the same as shown here) Verified on R14B03 running on FreeBSD 8.2-RELEASE x86 and R14B03 running on RHEL v4 x86_64 for Kyoto University Supercomputer Thin Cluster. Kenji Rikitake _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs From michael.santos@REDACTED Thu Aug 25 19:58:14 2011 From: michael.santos@REDACTED (Michael Santos) Date: Thu, 25 Aug 2011 13:58:14 -0400 Subject: [erlang-bugs] a crypto function call crashes VM In-Reply-To: References: <20110825163727.GA6382@k2r.org> Message-ID: <20110825175814.GA14839@ecn.lan> On Thu, Aug 25, 2011 at 06:58:21PM +0200, Erik S?e S?rensen wrote: > Simpler version: > crypto:sha_update(list_to_binary(lists:seq(1,96)). Maybe even simpler: 1> crypto:sha_update(<<0:(95*8), 0>>, "x"). <<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,0,0,0,0,0,0,0, 120,...>> 2> crypto:sha_update(<<0:(95*8), 1>>, "x"). Segmentation fault The crypto NIF is crashing when doing a SHA_update() (crypto.c:502). Looks like an OpenSSL bug. "1" is set in the num field of the SHA_CTX struct. This segfaults too: #include #include #include #include int main (int argc, char *argv[]) { SHA_CTX ctx; u_char zero[sizeof(ctx)]; u_char buf[sizeof(ctx)]; (void)memset(&ctx, 0, sizeof(ctx)); (void)memset(zero, 0, sizeof(zero)); SHA_Init(&ctx); (void)memset(&ctx, 1, sizeof (ctx)); SHA_Update(&ctx, zero, sizeof(zero)); SHA_Final(buf, &ctx); return (0); } > Boundary: > 6> crypto:sha_update(list_to_binary([0 || _ <- lists:seq(1,96)]), "x"). > <<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,0,0,0,0,0,0,0, > 120,...>> > 7> crypto:sha_update(list_to_binary([1 || _ <- lists:seq(1,96)]), "x"). > Segmentation fault > > (Probably part of the binary is interpreted as a pointer, except when NULL.) > > ________________________________________ > Fra: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] På vegne af Kenji Rikitake [kenji.rikitake@REDACTED] > Sendt: 25. august 2011 18:37 > Til: erlang-bugs@REDACTED > Emne: [erlang-bugs] a crypto function call crashes VM > > Enter the following code to erl shell: > > crypto:sha_update( > list_to_binary(lists:reverse(binary_to_list(crypto:sha_init()))), "hello"). > > Segmentation fault occurs and VM crashed with the core dump. > > This is originally reported at > https://twitter.com/#!/szktty/status/106761685284564992 > by Tetsuya Suzuki (Twitter: @szktty) > (Tweet in Japanese but the code is the same as shown here) > > Verified on > R14B03 running on FreeBSD 8.2-RELEASE x86 > and R14B03 running on RHEL v4 x86_64 > for Kyoto University Supercomputer Thin Cluster. > > Kenji Rikitake > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From tetsuya.suzuki@REDACTED Fri Aug 26 12:33:56 2011 From: tetsuya.suzuki@REDACTED (SUZUKI Tetsuya) Date: Fri, 26 Aug 2011 19:33:56 +0900 Subject: [erlang-bugs] a crypto function call crashes VM Message-ID: Hi, BEAM crashes when the following message digest functions using contexts in crypto module receive some binary as context. (Environment: Erlang R14B03, Mac OS X 10.6.8 (i386, MacBook Air). * md4_update/2 * md4_final/2 * md5_update/2 * md5_final/2 * sha_update/2 * sha_final/2 * hmac_update/2 * hmac_final/2 Conditions of the binary I tried are: * The same length as context generated by context initialization functions (*_init/0 or hmac_init/2). For example in my environment, context length of md5_init/0 is 92 and sha_init/0 is 96. * The content is reversed binary (context) generated by context initialization functions. An example: $ erl Erlang R14B03 (erts-5.8.4) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.8.4 (abort with ^G) 1> C1 = crypto:sha_init(). <<1,35,69,103,137,171,205,239,254,220,186,152,118,84,50, 16,240,225,210,195,0,0,0,0,0,0,0,0,114,...>> 2> C2 = list_to_binary(lists:reverse(binary_to_list(C1))). <<0,0,0,0,213,8,1,216,13,25,10,215,13,17,10,64,23,213,13, 35,59,35,213,13,48,130,19,217,13,...>> 3> crypto:sha_update(C2, "hello"). Segmentation fault If length of context is different from one generated by context initialization functions, BEAM does not crash: 1> C1 = crypto:sha_init(). <<1,35,69,103,137,171,205,239,254,220,186,152,118,84,50, 16,240,225,210,195,0,0,0,0,0,0,0,0,19,...>> 2> C2 = list_to_binary(lists:reverse(binary_to_list(C1))). <<0,0,0,0,3,3,67,240,80,5,125,67,99,77,45,71,72,1,72,77, 61,3,67,64,242,67,71,77,43,...>> 3> C3 = list_to_binary(binary_to_list(C2) ++ "abc"). <<0,0,0,0,3,3,67,240,80,5,125,67,99,77,45,71,72,1,72,77, 61,3,67,64,242,67,71,77,43,...>> 4> crypto:sha_update(C3, "hello"). ** exception error: bad argument in function crypto:sha_update/2 called as crypto:sha_update(<<0,0,0,0,3,3,67,240,80,5,125,67,99,77,45,71, 72,1,72,77,61,3,67,64,242,67,71,77,...>>, "hello") I think NIF implementation of the functions cause the crash in otp_src_R14B03/lib/crypto/c_src/crypto.c. For MD5, in static md5_init(), line 442: MD5_Init((MD5_CTX *) enif_make_new_binary(env, MD5_CTX_LEN, &ret)); In static md5_update(), line 450-451: MD5_CTX* new_ctx; ErlNifBinary ctx_bin, data_bin; ERL_NIF_TERM ret; if (!enif_inspect_binary(env, argv[0], &ctx_bin) /* here */ || ctx_bin.size != MD5_CTX_LEN /* here */ ... The md5_update() implementation uses a binary of first argument as struct MD5_CTX with only checking length of the binary and MD5_CTX. However, it is not ensured that the binary is byte representation of struct MD5_CTX. Other digest functions (MD4, SHA1, HMAC) have the same problem. If the functions communicate with BEAM using resource objects include MD5_CTX data, BEAM may not crash. --- SUZUKI Tetsuya From suzuki@REDACTED Sat Aug 27 10:03:18 2011 From: suzuki@REDACTED (SUZUKI Tetsuya) Date: Sat, 27 Aug 2011 17:03:18 +0900 Subject: [erlang-bugs] a crypto function call crashes VM In-Reply-To: References: Message-ID: Sorry, I showed wrong code in md5_update(). This code copies a received binary to a MD5_CTX variable. In static md5_update(), line 456: memcpy(new_ctx, ctx_bin.data, MD5_CTX_LEN); From paul.joseph.davis@REDACTED Wed Aug 31 20:20:54 2011 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Wed, 31 Aug 2011 13:20:54 -0500 Subject: [erlang-bugs] Bug in enif_compare/2 for bignums Message-ID: Hello, I think I've uncovered a bug in enif_compare/2 for bignums. Converting the same arguments to ErlNifSInt64 values and using C comparison returns the correct result when enif_compare does not. There's a reduced test case at [1]. If there's nothing obvious I'll spend some time later digging into Erlang to see if I can spot the bug. Thanks, Paul Davis [1] https://github.com/davisp/enif_cmp_bug