Where I'm concerned is in vsnprintf.h:fnumber(), which converts a
double-precision float to an ASCII hex float representation (like the
GNU %A extension).
The function first takes an early-out for infinties and nans, and then
it repeatedly outputs the leftmost hex digit untiil the remaining part
of the number is all 0s.
When debugging this, I discovered that printing inf or nan locked the
machine up for several seconds, and then encountered a kernel null
pointer dereference. This is because for inf and nan the while()
condition would never become false. ch() eventually tries to store at
an unmapped address (it respects the 'end' pointer but not after the
pointer wraps around to the smallest possible address).
If you are using --enable-simulator then this code is never reached,
because we just use the libc vsnprintf.
static char *fnumber(char *buf, char *end, double num)
{
...
if(signbit(num)) buf = ch(buf, end, '-');
if(isnan(num)) { buf = st(buf, end, "NaN"); return buf; }
if(isinf(num)) { buf = st(buf, end, "Inf"); return buf; }
...
while(mantissa) {
/* remaning digits, if any */
i = (int)floor(mantissa);
buf = ch(buf, end, large_digits[i]);
mantissa = 16 * (mantissa - i);
}
...
}
You can test whether this is a problem simply by installing the
numbers.c component and then trying to 'loadrt' it. You should quickly
get a failed load message and then find messages like the following in
dmesg:
[ 1047.950633] 0x0P+0
[ 1047.950640] -0x0P+0
[ 1047.950644] 0x8P-3
[ 1047.950647] -0x8P-3
[ 1047.950651] 0x9.24D692CA61BE8P+329
[ 1047.950656] -0x9.24D692CA61BE8P+329
[ 1047.950661] 0xD.FF9772470298P-336
[ 1047.950665] -0xD.FF9772470298P-336
[ 1047.950670] 0xC.90FDAA22168CP-2
[ 1047.950672] builtin inf() good
[ 1047.950675] Inf
[ 1047.950678] -Inf
[ 1047.950680] builtin nan() good
[ 1047.950683] NaN
(if your machine doesn't use ieee double representation then the less
significant figures may differ, but the code depends on frexp to
separate mantissa and exponent, not the specific layout of IEEE
floating-point values on x86, so I expect it to be OK)
numbers.c is at http://emergent.unpy.net/files/sandbox/numbers.c
Jeff
------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
