Re: [DNG] int essid_alloc is causing valgrind to report a series of errors
Peter Olson writes: >> On October 14, 2015 at 3:20 PM Edward Bartolo wrote: >> >> >> This is another part of the backend code where valgrind is saying: >> >> ==5501== 5 errors in context 1 of 3: >> ==5501== Use of uninitialised value of size 8 >> ==5501==at 0x5172AFC: strtod_l_internal (strtod_l.c:889) >> ==5501==by 0x403856: getRadiatingWifiList (automated_scanner.c:265) >> ==5501==by 0x403BDC: autoWirelessScanPlus (automated_scanner.c:386) >> ==5501==by 0x40400D: autoWirelessScanPlus_RN (automated_scanner.c:549) >> ==5501==by 0x402E2C: main (backend.c:251) >> ==5501== Uninitialised value was created by a stack allocation >> ==5501==at 0x4034BB: getRadiatingWifiList (automated_scanner.c:155) [...] >> tmp_wifi_quality->quality = strtod(tmpstr, >> NULL); > > You should probably investigate the area around line 155. The code shouldn't use tmpstr in this way at all because The strtod(), strtof(), and strtold() functions convert the initial portion of the string pointed to by nptr to double, float, and long double representation, respectively. [...] If endptr is not NULL, a pointer to the character after the last character used in the conversion is stored in the location referenced by endptr. [strtod(3)] In other words, strtod is capable of finding the end of the number to be converted on its own. > = > > I have some other other comments. > >> tmp_wifi_quality = calloc(sizeof(wifi_quality), >> 1); > > The canonical way to write this is > >> tmp_wifi_quality = calloc(1, >> sizeof(wifi_quality)); > > The calloc call is designed to return an array of N structures properly > aligned > for the requirements of the machine (for embedded pointers, as an > example). The malloc() and calloc() functions return a pointer to the allocated memory that is suitably aligned for any kind of variable. [calloc(3)] The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated [ISO/IEC 9899:1999 (E), 7.20.3|1] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] int essid_alloc is causing valgrind to report a series of errors
Peter Olson writes:
>> On October 14, 2015 at 3:20 PM Edward Bartolo wrote:
>>
>>
>> This is another part of the backend code where valgrind is saying:
>>
>> ==5501== 5 errors in context 1 of 3:
>> ==5501== Use of uninitialised value of size 8
>> ==5501==at 0x5172AFC: strtod_l_internal (strtod_l.c:889)
>> ==5501==by 0x403856: getRadiatingWifiList (automated_scanner.c:265)
[...]
> This diagnostic bothers me:
>
>> ==5501== Uninitialised value was created by a stack allocation
>> ==5501==at 0x4034BB: getRadiatingWifiList (automated_scanner.c:155)
>
> This is hundreds of lines away from
>
>> ==5501==by 0x403856: getRadiatingWifiList
>> (automated_scanner.c:265)
"ELARGEFUNCTION"
> which is presumably
>
>> tmp_wifi_quality->quality = strtod(tmpstr,
>> NULL);
>
> You should probably investigate the area around line 155.
Since the explanation may be useful: 'Stack allocations' usually happen
at the beginning of a function, regardless of the point of a variable
declaration. Eg, when running the following test/ example program:
--
/* 1 */ #include
/* 2 */ #include
/* 3 */ #include
/* 4 */
/* 5 */ char const scan_buffer[] = "yadda Signal level=5.9 fff";
/* 6 */
/* 7 */ int main(void)
/* 8 */ {
/* 9 */ double d;
/* 10 */
/* 11 */char* substr = strstr((char *) scan_buffer, "Signal
level=");
/* 12 */substr = strstr(substr, "=");
/* 13 */char* endstr = strstr(substr + 1, " ");
/* 14 */char tmpstr[8];
/* 15 */strncpy(tmpstr, substr + 1, endstr - substr - 1);
/* 16 */tmpstr[endstr - substr + 1] = '\0';
/* 17 */
/* 18 */d = strtod(tmpstr, NULL);
/* 19 */printf("%f\n", d);
/* 20 */
/* 21 */return 0;
/* 22 */}
--
via
$valgrind --track-origins=yes ./a.out
one gets the following (partial) output:
==27072== Conditional jump or move depends on uninitialised value(s)
==27072==at 0x4E63430: strtod_l_internal (strtod_l.c:803)
==27072==by 0x40066B: main (aa.c:18)
==27072== Uninitialised value was created by a stack allocation
==27072==at 0x4005D4: main (aa.c:8)
==27072==
==27072== Use of uninitialised value of size 8
==27072==at 0x4E6343E: strtod_l_internal (strtod_l.c:818)
==27072==by 0x40066B: main (aa.c:18)
==27072== Uninitialised value was created by a stack allocation
==27072==at 0x4005D4: main (aa.c:8)
The uninitialized values is used on line 18 but reported as allocated on
line 8 which is the start of the function.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] int essid_alloc is causing valgrind to report a series of errors
Suppose this is a string in which we are interested:
The value of Pi is 3.142 approximately.
The index of the space preceding Pi is: 18 - 1 = 17
The index of the space after Pi is: 24 - 1 = 23
The length of the decimal number is: 5 characters,
which is also: 23 - 17 - 1 = 5
If we were to copy the string representing the decimal number as I
actually did in my code, the null char would have been at: 5
My mistake was to add 1 instead of subtracting 1, ie, my mistake was
endptr - substr + 1
On 15/10/2015, Rainer Weikusat wrote:
> Peter Olson writes:
>>> On October 14, 2015 at 3:20 PM Edward Bartolo wrote:
>>>
>>>
>>> This is another part of the backend code where valgrind is saying:
>>>
>>> ==5501== 5 errors in context 1 of 3:
>>> ==5501== Use of uninitialised value of size 8
>>> ==5501==at 0x5172AFC: strtod_l_internal (strtod_l.c:889)
>>> ==5501==by 0x403856: getRadiatingWifiList (automated_scanner.c:265)
>
> [...]
>
>> This diagnostic bothers me:
>>
>>> ==5501== Uninitialised value was created by a stack allocation
>>> ==5501==at 0x4034BB: getRadiatingWifiList (automated_scanner.c:155)
>>
>> This is hundreds of lines away from
>>
>>> ==5501==by 0x403856: getRadiatingWifiList
>>> (automated_scanner.c:265)
>
> "ELARGEFUNCTION"
>
>> which is presumably
>>
>>> tmp_wifi_quality->quality = strtod(tmpstr,
>>> NULL);
>>
>> You should probably investigate the area around line 155.
>
> Since the explanation may be useful: 'Stack allocations' usually happen
> at the beginning of a function, regardless of the point of a variable
> declaration. Eg, when running the following test/ example program:
>
> --
> /* 1 */ #include
> /* 2 */ #include
> /* 3 */ #include
> /* 4 */
> /* 5 */ char const scan_buffer[] = "yadda Signal level=5.9 fff";
> /* 6 */
> /* 7 */ int main(void)
> /* 8 */ {
> /* 9 */ double d;
> /* 10 */
> /* 11 */char* substr = strstr((char *) scan_buffer, "Signal
> level=");
> /* 12 */substr = strstr(substr, "=");
> /* 13 */char* endstr = strstr(substr + 1, " ");
> /* 14 */char tmpstr[8];
> /* 15 */strncpy(tmpstr, substr + 1, endstr - substr - 1);
> /* 16 */tmpstr[endstr - substr + 1] = '\0';
> /* 17 */
> /* 18 */d = strtod(tmpstr, NULL);
> /* 19 */printf("%f\n", d);
> /* 20 */
> /* 21 */return 0;
> /* 22 */}
> --
>
> via
>
> $valgrind --track-origins=yes ./a.out
>
> one gets the following (partial) output:
>
> ==27072== Conditional jump or move depends on uninitialised value(s)
> ==27072==at 0x4E63430: strtod_l_internal (strtod_l.c:803)
> ==27072==by 0x40066B: main (aa.c:18)
> ==27072== Uninitialised value was created by a stack allocation
> ==27072==at 0x4005D4: main (aa.c:8)
> ==27072==
> ==27072== Use of uninitialised value of size 8
> ==27072==at 0x4E6343E: strtod_l_internal (strtod_l.c:818)
> ==27072==by 0x40066B: main (aa.c:18)
> ==27072== Uninitialised value was created by a stack allocation
> ==27072==at 0x4005D4: main (aa.c:8)
>
> The uninitialized values is used on line 18 but reported as allocated on
> line 8 which is the start of the function.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Pushed debugged code for backend memory leakages
Hi, Although, like all software projects, the final debugging phase never ends, I pushed the latest changes to address memory leakages in backend and some programmatic inexactitudes. I would like to also draw attention to an outstanding BUG I discovered. This is exhibited when netman GUI tries to connect to an inexistent wifi transceiver or to an Ethernet device to which no network cables are connected. I am thinking about a CLI command to parse for such a situation so that users of netman GUI would be able to disconnect 'zombie' connections. This is 'ps aux' which lists all running processes. Searching for running instances of dhclient and looking in such records for the presence of wlanx, ethx or whatever udev calls them, looks like another way to distinguish genuine working connections from 'zombie' connections. If you have better suggestions as to a more efficient CLI, please, make your suggestions. Edward ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] int essid_alloc is causing valgrind to report a series, of errors
Hi Edward,
You are pointing *result to a pointer 'tmp' declared locally inside the
function 'essid_alloc', whose value will be lost outside it...
Is it right?
Aitor.
On 14/10/15 21:29, Edward Bartolo wrote:
int essid_alloc(
size_t length,
char ** result
) {
char * tmp;
if(length==0 || !result)
return EINVAL;
tmp = (char *) calloc(length, 1);
if(!tmp)
return ENOMEM;
*result = tmp;
return 0;
}
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] int essid_alloc is causing valgrind to report a series, of errors
aitor_czr writes: > Hi Edward, > > You are pointing *result to a pointer 'tmp' declared locally inside > the function 'essid_alloc', whose value will be lost outside it... > > Is it right? No, it's not. At the point of the assignment, the value of tmp is some value returned by calloc. And that's a pointer to some memory on the heap which won't be deallocated automatically. In order to "point result to the pointer 'tmp'" the line would need to read *result = &tmp; which wouldn't compile because *result is a char * and &tmp a char **. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Am I in the Devuan land?
Hi, Few days ago I upgraded jessie 8.0 to Devuan. After that due to some applications' issues, I went back to jessie 8.2 by replacing package repository servers in /etc/apt/sources.list file. -Computer- Processor : 6x AMD FX(tm)-6100 Six-Core Processor Memory : 7919MB (662MB used) Operating System : Debian GNU/Linux 8.2 Date/Time : Tue 13 Oct 2015 08:49:46 AM KST -Display- Resolution : 1440x900 pixels OpenGL Renderer : Gallium 0.4 on AMD RS780 X11 Vendor : The X.Org Foundation -Multimedia- Audio Adapter : HDA-Intel - HDA ATI SB -Input Devices- Logitech USB Optical Mouse CHICONY HP Basic USB Keyboard Power Button Power Button PC Speaker HDA ATI SB Front Mic HDA ATI SB Rear Mic HDA ATI SB Line HDA ATI SB Line Out HDA ATI SB Front Headphone -Printers (CUPS)- HP_LaserJet_P1005 PDF : Default No LSB modules are available. $ lsd_release -a Distributor ID: Devuan Description: Devuan GNU/Linux 8.2 (jessie) Release: 8.2 Codename: jessie $ ps aux PID TTY STAT TIME COMMAND 1 ?Ss 0:00 init [2] 2 ?S 0:00 [kthreadd] 3 ?S 0:02 [ksoftirqd/0] 5 ?S< 0:00 [kworker/0:0H] 7 ?S 0:33 [rcu_sched] 8 ?S 0:00 [rcu_bh] 9 ?S 0:00 [migration/0] 10 ?S 0:00 [watchdog/0] 11 ?S 0:00 [watchdog/1] 12 ?S 0:00 [migration/1] 13 ?S 0:00 [ksoftirqd/1] 15 ?S< 0:00 [kworker/1:0H] 16 ?S 0:00 [watchdog/2] 17 ?S 0:00 [migration/2] 18 ?S 0:02 [ksoftirqd/2] 20 ?S< 0:00 [kworker/2:0H] 21 ?S 0:00 [watchdog/3] 22 ?S 0:00 [migration/3] Regards, Hughe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
