<div dir="ltr">You did is a great piece of detective work. This really piqued my interest and I did a bit of playing around. <br><br>It seems that the failures always occur at the same point in the sequence. What I did is add a sequence number to each conversion, then print them out. I conjectured that the failed values are actually all integers but internally incorrectly represented so that the inequality test fails. I also looked at the C code for the BIF for string:to_integer, which was ... interesting.<br>
<br>The bottom line is that every time I ran the test code, the conversions always failed at the same points (ran on Windows XP SP3, Erlang R12B-3). I tried varying the erl parameters (turning off SMP, fiddling with memory allocation, etc) but to no avail.<br>
<br>46> nfail2:test(1000000).<br>6 bad conversions: [{308,{134217728,",\n"}},<br> {500,{134217728,",\n"}},<br> {1313,{134217728,",\n"}},<br> {3589,{134217728,",\n"}},<br>
{5631,{134217728,",\n"}},<br> {61947,{134217728,",\n"}}]<br><br>The only thing I could think of that would vary as the code ran is the memory allocation. From lookoing at the C code, I could see that bignums need heap allocation (a macro called HAlloc). If there was something in the to_integer C code that messed up the process heap (by growing the heap by too small an amount) so that every now and then, data was written a tiny bit past the end of the heap without crashing Erlang, this could account for the behavior. The reason the numbers are always in the same places is because there are heap reallocations as the heap grows, and if the bug is consistent, it will always screw up in the same places.<br>
<br>To test this theory, I started Erlang with the +h flag that sets the heap for each process to an initial size, to see if delaying heap allocation fixed the problem. <br><br>It did fix the problem, sort of, well, it postponed it, as you will see.<br>
<br>G:\misc>erl +h 10000<br>Eshell V5.6 (abort with ^G)<br>1> nfail2:test(10000).<br>0 bad conversions: []<br>0<br>2> nfail2:test(100000).<br>2 bad conversions: [{5463,{134217728,",\n"}},{8964,{134217728,",\n"}}]<br>
2<br><br>Notice that the places in which the error occurs are now different.<br><br>Hope this helps.<br><br><br><div class="gmail_quote">2008/9/1 Lev Walkin <span dir="ltr"><<a href="mailto:vlm@lionet.info">vlm@lionet.info</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Hi,<br>
<br>
<br>
we all love string to integer conversion routines, such as<br>
string:to_integer/1 or erlang:list_to_integer/1.<br>
<br>
The functions serve us well and indeed provide us with advertised<br>
functionality almost every time.<br>
<br>
However, we've noticed some oddity on our production system which,<br>
after two weeks of jaw-dropping musings, has boiled down to a strange<br>
idempotence violation in the string:to_integer/1 implementation.<br>
<br>
To those of you impatient enough, please look into the code<br>
attached and try running it as nfail:test(10000) and go down from<br>
there.<br>
<br>
Here's that string:to_integer/1 function, having the following<br>
signature:<br>
<br>
string:to_integer(String) -> {Int,Rest} | {error,Reason}<br>
<br>
Here's a typical invocation resulting in a number and the<br>
rest of the unparsed string returned:<br>
<br>
36> string:to_integer("134217728,\n").<br>
{134217728,",\n"}<br>
37><br>
<br>
What would happen if we did it once more?<br>
<br>
37> string:to_integer("134217728,\n").<br>
{134217728,",\n"}<br>
38><br>
<br>
By this time we can be reasonably sure that string:to_integer/1 will<br>
return the same output given the same input. We have seen that this<br>
is indeed the case by testing it twice. Could it be that testing<br>
it N times would result in a bad behavior? Nah, unlikely, you say.<br>
<br>
If you haven't looked at the attached code, it is time to do so.<br>
In the code, we create a list of N results of the string:to_integer/1<br>
application, like this:<br>
<br>
iterate(0, Acc) -> Acc;<br>
iterate(N, Acc) -><br>
iterate(N - 1,<br>
[case string:to_integer("134217728,\n") of<br>
{Int, _} -> Int<br>
end | Acc]).<br>
<br>
This code utilizes tail recursion with an accumulator list<br>
which gets prepended N times by string:to_integer/1 output,<br>
undoubtedly an integer. (Implementation with a map over lists:seq()<br>
output can do as well).<br>
<br>
So we spawn and run this iterate/2 function, appropriately checking<br>
that the list consists only of integers with value 134217728:<br>
<br>
test(N) -><br>
{Self, Ref} = {self(), make_ref()},<br>
spawn_opt(fun()-><br>
L = iterate(N, []),<br>
% Filter out non-conforming entries<br>
BadList = [X || X <- L, X =/= 134217728],<br>
BadLen = length(BadList),<br>
% Here, BadLen should always be 0!<br>
io:format("~b bad conversions: ~p~n", [BadLen, BadList]),<br>
Self ! {done, Ref, BadLen}<br>
end,<br>
[link,{fullsweep_after,0}]),<br>
receive {done, Ref, Len} -> Len end.<br>
<br>
Based on the smoke tests above, this code should always result<br>
in something like this:<br>
<br>
38> nfail:test(100).<br>
0 bad conversions: []<br>
0<br>
39><br>
<br>
But let's start testing it thorougly, as if not believing ourselves<br>
that such a simple function could possibly fail at times:<br>
<br>
[vlm@g4:~]> erl<br>
Erlang (BEAM) emulator version 5.6.3 [source] [async-threads:0] [kernel-poll:false]<br>
<br>
Eshell V5.6.3 (abort with ^G)<br>
1> c(nfail).<br>
{ok,nfail}<br>
2> nfail:test(1).<br>
0 bad conversions: []<br>
0<br>
3> nfail:test(2).<br>
0 bad conversions: []<br>
0<br>
4> nfail:test(100).<br>
0 bad conversions: []<br>
0<br>
5> nfail:test(1000).<br>
2 bad conversions: [{134217728,",\n"},{134217728,",\n"}]<br>
2<br>
6> nfail:test(10000).<br>
5 bad conversions: [{134217728,",\n"},<br>
{134217728,",\n"},<br>
{134217728,",\n"},<br>
{134217728,",\n"},<br>
{134217728,",\n"}]<br>
5<br>
7><br>
...<br>
32> nfail:test(810).<br>
0 bad conversions: []<br>
0<br>
33> nfail:test(811).<br>
2 bad conversions: [{134217728,",\n"},{134217728,",\n"}]<br>
2<br>
34> nfail:test(810).<br>
0 bad conversions: []<br>
0<br>
35> nfail:test(811).<br>
2 bad conversions: [{134217728,",\n"},{134217728,",\n"}]<br>
2<br>
36><br>
<br>
<br>
As you see, string:to_integer/1 consistently generates bad entries<br>
which contain {134217728,",\n"} instead of 134217728, but only<br>
when the number of invocation reaches about 1000 (811 in this<br>
particular sequence of steps).<br>
<br>
Perhaps this is a platform glitch? The above code was being executed<br>
on a ppc (G4) Mac OS X 10.5 with R12B-3 (32-bit) built from scratch. Here's what Sun sparc v9 with Solaris 10 thinks about that test case:<br>
<br>
[vlm@sparc:~]> erl<br>
Erlang (BEAM) emulator version 5.6.3 [source] [async-threads:0] [hipe] [kernel-poll:false]<br>
<br>
Eshell V5.6.3 (abort with ^G)<br>
1> c(nfail).<br>
{ok,nfail}<br>
2> nfail:test(100).<br>
1 bad conversions: [{134217728,",\n"}]<br>
1<br>
3> nfail:test(1000).<br>
3 bad conversions: [{134217728,",\n"},{134217728,",\n"},{134217728,",\n"}]<br>
3<br>
4> nfail:test(10).<br>
0 bad conversions: []<br>
0<br>
5> nfail:test(50).<br>
0 bad conversions: []<br>
0<br>
6> c(nfail, [native]).<br>
{ok,nfail}<br>
7> nfail:test(500).<br>
4 bad conversions: [{134217728,",\n"},<br>
{134217728,",\n"},<br>
{134217728,",\n"},<br>
{134217728,",\n"}]<br>
4<br>
8><br>
<br>
And here's what 64-bit Intel box (am64, FreeBSD 6.3) thinks:<br>
<br>
[vlm@intel ~]$ erl<br>
Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [async-threads:0] [hipe] [kernel-poll:false]<br>
<br>
Eshell V5.6.3 (abort with ^G)<br>
1> c(nfail).<br>
{ok,nfail}<br>
2> nfail:test(100).<br>
0 bad conversions: []<br>
0<br>
3> nfail:test(1000).<br>
0 bad conversions: []<br>
0<br>
4> nfail:test(10000).<br>
0 bad conversions: []<br>
0<br>
5> nfail:test(100000).<br>
0 bad conversions: []<br>
0<br>
6> nfail:test(1000000).<br>
0 bad conversions: []<br>
0<br>
7><br>
<br>
Oops, it went very well, suprisingly. Perhaps, it is a purely<br>
non-Intel chip problem? Let's try it on a non 64bit machine,<br>
such as Pentium D under Microsoft Windows Vista™ in 32-bit mode:<br>
<br>
Erlang (BEAM) emulator version 5.6.3 [smp:2] [async-threads:0]<br>
<br>
Eshell V5.6.3 (abort with ^G)<br>
1> c('c:/tmp/nfail.erl').<br>
{ok,nfail}<br>
2> nfail:test(100).<br>
0 bad conversions: []<br>
0<br>
3> nfail:test(1000).<br>
2 bad conversions: [{134217728,",\n"},{134217728,",\n"}]<br>
2<br>
4><br>
<br>
Aha! See the pattern: 32-bit Erlang installations on many hardware<br>
platforms are having very similar problems. They are unable to<br>
consistently convert a string containing an integer into an integer<br>
value. Incidentally enough, the integer value for which Erlang<br>
starts to misbehave is 134217728, which is 2^27. Trying it with<br>
value "134217727" or lower does not create this idempotence problem.<br>
Trying R11B-5 under Windows Vista™ 32-bit does not exhibit such<br>
problem either, so it must be a specific issue to R12.<br>
<br>
Please advise.<br>
<br>
<br>
P.S. Thanks to Denis Titoruk and Vladimir Serov for investigating<br>
this issue and coming up with a short test case.<br><font color="#888888">
<br>
-- <br>
Lev Walkin<br>
<a href="mailto:vlm@lionet.info" target="_blank">vlm@lionet.info</a><br>
</font><br>-module(nfail).<br>
-export([test/1]).<br>
<br>
iterate(0, Acc) -> Acc;<br>
iterate(N, Acc) -><br>
iterate(N - 1,<br>
[case string:to_integer("134217728,\n") of<br>
{Int, _} -> Int<br>
end | Acc]).<br>
<br>
test(N) -><br>
{Self, Ref} = {self(), make_ref()},<br>
spawn_opt(fun()-><br>
L = iterate(N, []),<br>
BadList = [X || X <- L, X =/= 134217728],<br>
BadLen = length(BadList),<br>
io:format("~b bad conversions: ~p~n", [BadLen, BadList]),<br>
Self ! {done, Ref, BadLen}<br>
end,<br>
[link,{fullsweep_after,0}]),<br>
receive {done, Ref, Len} -> Len end.<br>
<br>_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-bugs</a><br></blockquote></div><br><br clear="all"><br>-- <br>For every expert there is an equal and opposite expert - Arthur C. Clarke<br>
</div>