user12345
Posts: 58
Joined: Mon Dec 22, 2014 7:06 pm

gcc xprintf nan bug librtlsdr

Thu May 17, 2018 2:08 pm

rtl_power (original)shows trash values or lets say it display a string instead of a number "nan".
It works on a real computer.
I have a modified rtl_power version, moving around some global variables into functions solves 1 Output.
But i cant do this for any variables.

So i think RPI/Raspbian gcc is buggy, cause it output different things on different computer and strings instead of numbers.
Any way to solve this?

User avatar
PeterO
Posts: 4237
Joined: Sun Jul 22, 2012 4:14 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 2:14 pm

WIth out some sample code that demonstrates the problem it's hard to see how anyone is going to be able to help you.

And making comments like "on a real computer" won't encourage us to help you either :shock:

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

user12345
Posts: 58
Joined: Mon Dec 22, 2014 7:06 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 3:11 pm

PeterO wrote:
Thu May 17, 2018 2:14 pm
WIth out some sample code that demonstrates the problem it's hard to see how anyone is going to be able to help you.

And making comments like "on a real computer" won't encourage us to help you either :shock:

PeterO
double dbm;
fprintf(file, "%.2f, ", dbm);
fprintf(file, "%.2f\n", dbm);

Thats the rtl_power.c from the "librtlsdr" package, its free available but i dont think that iam allowed to Post the whole sourcecode.
My modified code is almost the same, but it first collect all dbm and then print it.
The values goes from -41 to -18
I doesnt know that a raspberry is holy for some people.
I am of course annoyed that basics like wifi or compiling a program dont work but with "real computer" i mean a Desktop x86 Computer with Linux.

ejolson
Posts: 1836
Joined: Tue Mar 18, 2014 11:47 am

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 3:40 pm

user12345 wrote:
Thu May 17, 2018 3:11 pm
PeterO wrote:
Thu May 17, 2018 2:14 pm
WIth out some sample code that demonstrates the problem it's hard to see how anyone is going to be able to help you.

And making comments like "on a real computer" won't encourage us to help you either :shock:

PeterO
double dbm;
fprintf(file, "%.2f, ", dbm);
fprintf(file, "%.2f\n", dbm);

Thats the rtl_power.c from the "librtlsdr" package, its free available but i dont think that iam allowed to Post the whole sourcecode.
My modified code is almost the same, but it first collect all dbm and then print it.
The values goes from -41 to -18
I doesnt know that a raspberry is holy for some people.
I am of course annoyed that basics like wifi or compiling a program dont work but with "real computer" i mean a Desktop x86 Computer with Linux.
In C local variables are allocated from the stack. If local variables are not initialised, they will contain what ever data was left over from previous use of the stack. This is by design for efficiency. There are thousands of bit patterns which mean not a number in the IEEE floating point standard used by all current computing hardware. Specifically, for double precision we have
A signalling NaN is represented by any bit pattern
between 7FF0000000000001 and 7FF7FFFFFFFFFFFF or
between FFF0000000000001 and FFF7FFFFFFFFFFFF
A quiet NaN is represented by any bit pattern
between 7FF8000000000000 and 7FFFFFFFFFFFFFFF or
between FFF8000000000000 and FFFFFFFFFFFFFFFF
Differences in runtime environments imply that x86 and ARM architectures leave different bit patterns on the stack that can be picked up by uninitialised variables. The solution is don't print the values of uninitialised variables and expect sensible output.

User avatar
PeterO
Posts: 4237
Joined: Sun Jul 22, 2012 4:14 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 4:13 pm

Is this the code you are complaining about ?

Code: Select all


void csv_dbm(struct tuning_state *ts)
{
	int i, len, ds, i1, i2, bw2, bin_count;
	long tmp;
	double dbm;
	len = 1 << ts->bin_e;
	ds = ts->downsample;
	/* fix FFT stuff quirks */
	if (ts->bin_e > 0) {
		/* nuke DC component (not effective for all windows) */
		ts->avg[0] = ts->avg[1];
		/* FFT is translated by 180 degrees */
		for (i=0; i<len/2; i++) {
			tmp = ts->avg[i];
			ts->avg[i] = ts->avg[i+len/2];
			ts->avg[i+len/2] = tmp;
		}
	}
	/* Hz low, Hz high, Hz step, samples, dbm, dbm, ... */
	bin_count = (int)((double)len * (1.0 - ts->crop));
	bw2 = (int)(((double)ts->rate * (double)bin_count) / (len * 2 * ds));
	fprintf(file, "%i, %i, %.2f, %i, ", ts->freq - bw2, ts->freq + bw2,
		(double)ts->rate / (double)(len*ds), ts->samples);
	// something seems off with the dbm math
	i1 = 0 + (int)((double)len * ts->crop * 0.5);
	i2 = (len-1) - (int)((double)len * ts->crop * 0.5);
	for (i=i1; i<=i2; i++) {
		dbm  = (double)ts->avg[i];
		dbm /= (double)ts->rate;
		dbm /= (double)ts->samples;
		dbm  = 10 * log10(dbm);
		fprintf(file, "%.2f, ", dbm);
	}
	dbm = (double)ts->avg[i2] / ((double)ts->rate * (double)ts->samples);
	if (ts->bin_e == 0) {
		dbm = ((double)ts->avg[0] / \
		((double)ts->rate * (double)ts->samples));}
	dbm  = 10 * log10(dbm);
	fprintf(file, "%.2f\n", dbm);
	for (i=0; i<len; i++) {
		ts->avg[i] = 0L;
	}
	ts->samples = 0;
}
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

user12345
Posts: 58
Joined: Mon Dec 22, 2014 7:06 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 4:29 pm

ejolson wrote:
Thu May 17, 2018 3:40 pm
In C local variables are allocated from the stack. If local variables are not initialised, they will contain what ever data was left over from previous use of the stack.
..
Differences in runtime environments imply that x86 and ARM architectures leave different bit patterns on the stack that can be picked up by uninitialised variables. The solution is don't print the values of uninitialised variables and expect sensible output.
If that happend ggc would print a warning like "x is uninitalised in function y".

PeterO wrote:
Thu May 17, 2018 4:13 pm
Is this the code you are complaining about ?
Yes it is.

User avatar
PeterO
Posts: 4237
Joined: Sun Jul 22, 2012 4:14 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 4:37 pm

Are you sure the value of dbm is greater than zero before taking the log ?

Manual page for log says

Code: Select all

    If  x  is  negative  (including negative infinity), then a domain error
       occurs, and a NaN (not a number) is returned.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

user12345
Posts: 58
Joined: Mon Dec 22, 2014 7:06 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 6:49 pm

PeterO wrote:
Thu May 17, 2018 4:37 pm
Are you sure the value of dbm is greater than zero before taking the log ?

Manual page for log says

Code: Select all

    If  x  is  negative  (including negative infinity), then a domain error
       occurs, and a NaN (not a number) is returned.
PeterO
Dont really understand that. A floating point/double can be negative, that absoluty valid.
I set "double dbm=0" but this doesnt make a diffence.

Edit: that log, yes into log() comes negative numbers. This should be the same on x86 exept something other of the source gets corrupted bei gcc->arm.

jahboater
Posts: 2855
Joined: Wed Feb 04, 2015 6:38 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 7:02 pm

user12345 wrote:
Thu May 17, 2018 6:49 pm
PeterO wrote:
Thu May 17, 2018 4:37 pm
Are you sure the value of dbm is greater than zero before taking the log ?

Manual page for log says

Code: Select all

    If  x  is  negative  (including negative infinity), then a domain error
       occurs, and a NaN (not a number) is returned.
PeterO
Dont really understand that. A floating point/double can be negative, that absoluty valid.
Its not absolutely valid as an argument to log10. Basic math.
user12345 wrote:
Thu May 17, 2018 6:49 pm
I set "double dbm=0" but this doesnt make a diffence.
In that case see

Code: Select all

If x is zero, then a pole error occurs, and the functions return -HUGE_VAL, -HUGE_VALF, or
       -HUGE_VALL, respectively.
See "man log10" and "man 3 log" that it refers to.

Nothing to do with x86 or the Pi.
See annex F in the C11 standard :-
F.10.3.8 The log10 functions
— log10(±0) returns − ∞ and raises the ‘‘divide-by-zero’’ floating-point exception.
— log10(1) returns +0.
— log10(x) returns a NaN and raises the ‘‘invalid’’ floating-point exception for x < 0.
— log10(+ ∞ ) returns + ∞ .
Last edited by jahboater on Thu May 17, 2018 7:07 pm, edited 1 time in total.

user12345
Posts: 58
Joined: Mon Dec 22, 2014 7:06 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 7:06 pm

jahboater wrote:
Thu May 17, 2018 7:02 pm

See "man log10" and "man 3 log" that it refers to.
okay, i believe that.
Numbers on x86 that goes into log() are all positive.
Means gcc->arm trash the source at another point.

jahboater
Posts: 2855
Joined: Wed Feb 04, 2015 6:38 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 7:17 pm

user12345 wrote:
Thu May 17, 2018 7:06 pm
Means gcc->arm trash the source at another point.
Or it means that there some undefined behavior in your program that just happens, by pure luck, to work on an x86 platform :)

user12345
Posts: 58
Joined: Mon Dec 22, 2014 7:06 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 7:59 pm

jahboater wrote:
Thu May 17, 2018 7:17 pm
Or it means that there some undefined behavior in your program that just happens, by pure luck, to work on an x86 platform :)
Its not my own program, its librtlsdr and its example programs.
I dont say its impossible, but except of Little/Big Endian gcc would give a warning in such a case.
x86 and pi are both little endian.

User avatar
PeterO
Posts: 4237
Joined: Sun Jul 22, 2012 4:14 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 8:56 pm

user12345 wrote:
Thu May 17, 2018 7:59 pm
Its not my own program, its librtlsdr and its example programs.
You did say "I have a modified rtl_power version, moving around some global variables into functions" so maybe it is your fault ?
But if you still think it's a bug then you need to raise a bug on the librtlsdr github site, they are the people that you should be talking to.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

user12345
Posts: 58
Joined: Mon Dec 22, 2014 7:06 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 9:28 pm

PeterO wrote:
Thu May 17, 2018 8:56 pm
You did say "I have a modified rtl_power version, moving around some global variables into functions" so maybe it is your fault ?
But if you still think it's a bug then you need to raise a bug on the librtlsdr github site, they are the people that you should be talking to.
I used the original rtl_power version for testing. I have too have a modified version.

Think i found it already arm/rpi seems have 4 bytes for datatype "long" and x86 have 8bytes.

User avatar
PeterO
Posts: 4237
Joined: Sun Jul 22, 2012 4:14 pm

Re: gcc xprintf nan bug librtlsdr

Thu May 17, 2018 9:30 pm

user12345 wrote:
Thu May 17, 2018 9:28 pm
PeterO wrote:
Thu May 17, 2018 8:56 pm
You did say "I have a modified rtl_power version, moving around some global variables into functions" so maybe it is your fault ?
But if you still think it's a bug then you need to raise a bug on the librtlsdr github site, they are the people that you should be talking to.
I used the original rtl_power version for testing. I have too have a modified version.

Think i found it already arm/rpi seems have 4 bytes for datatype "long" and x86 have 8bytes.
So it's badly written (non-portable) code if it makes assumptions about data type sizes. 32/64 bit issues are not that hard to avoid.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

jahboater
Posts: 2855
Joined: Wed Feb 04, 2015 6:38 pm

Re: gcc xprintf nan bug librtlsdr

Fri May 18, 2018 6:44 am

+1
user12345 wrote:
Thu May 17, 2018 7:06 pm
Means gcc->arm trash the source at another point.
It is nothing to do with gcc or arm ....

use "int64_t" if you want 8 byte signed integers. Use "int32_t" or just plain "int" if you want 4 byte integers.
Only ever use long when you don't care about the size change between platforms.

Code: Select all

#include <inttypes.h>
#include <stdbool.h>
gets all the integer types and related definitions (since C99).

Return to “C/C++”

Who is online

Users browsing this forum: No registered users and 7 guests