Segmenting while reading a file

Beginner

Monday, May 12th 2008, 12:59pm

I am creating an application, where I will read data from /proc/stat file which contains cpu uasge data and plot the values of cpu usage with respect to time.

For this I am writing a Timer event which for every 1 sec it opens the file and read the data and plot.

In my application I am calling the timer event 126 times.

At the 30 th iteration of the timer event the apllication is segmenting withe following message .

/**********************************************************/

*** glibc detected *** ./cpu: malloc(): memory corruption: 0x0000000000679e90 ***
======= Backtrace: =========
/lib64/libc.so.6[0x36c4c6f0e4]
/lib64/libc.so.6(__libc_malloc+0x7d)[0x36c4c7086d]
/lib64/libc.so.6[0x36c4c5ecda]
./cpu(_ZN7QWidget11qt_propertyEiiP8QVariant+0xf06)[0x4059be]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN7QObject5eventEP6QEvent+0x66)[0x3e79560ff6]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN7QWidget5eventEP6QEvent+0x2

[0x3e79598518]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0x85)[0x3e795007d5]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0xa4)[0x3e79501ca4]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop14activateTimersEv+0x21c)[0x3e794f5bbc]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop13processEventsEj+0x4e1)[0x3e794af351]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop9enterLoopEv+0x41)[0x3e79517f91]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop4execEv+0x22)[0x3e79517e72]
./cpu(_ZN7QWidget5closeEb+0x253)[0x40552b]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x36c4c1da44]
./cpu(_ZN7QWidget5closeEb+0xc1)[0x405399]
======= Memory map: ========
00400000-00407000 r-xp 00000000 08:03 622657 /DEMO/cpu/cpu
00607000-00608000 rw-p 00007000 08:03 622657 /DEMO/cpu/cpu
00608000-006aa000 rw-p 00608000 00:00 0 [heap]
36c4800000-36c481a000 r-xp 00000000 08:03 98887 /lib64/ld-2.5.so
36c4a19000-36c4a1a000 r--p 00019000 08:03 98887 /lib64/ld-2.5.so
36c4a1a000-36c4a1b000 rw-p 0001a000 08:03 98887 /lib64/ld-2.5.so
36c4c00000-36c4d44000 r-xp 00000000 08:03 98888 /lib64/libc-2.5.so
36c4d44000-36c4f44000 ---p 00144000 08:03 98888 /lib64/libc-2.5.so

/*********************************************************/

From the above meesage I feel that memory corruption is happening , But how to resolve this memory corruption.

Please help me .

This post has been edited 1 times, last edit by "srinivasj" (May 12th 2008, 1:01pm)

T.M.F.

Trainee

Posts: 149

2

Tuesday, May 13th 2008, 2:04am

RE: Segmenting while reading a file

It will be easier to answet to your question if you provide some generic code which reproduce your problems. Strace is almost useless without source.

srinivasj

Beginner

Posts: 17

3

Tuesday, May 13th 2008, 4:23am

please find the code in the attached file.

Regards
-Srinivas

srinivasj has attached the following file:

cpuload.cpp (7.43 kB - 5 times downloaded - Last download: Jul 2nd 2008, 7:39am)

srinivasj

Beginner

Posts: 17

4

Tuesday, May 13th 2008, 8:06am

Please find the .cpp , .pro and Makefile of the application.

Regards,
Srinivas

srinivasj has attached the following files:

Makefil. (2.99 kB - 4 times downloaded - Last download: Jul 15th 2008, 3:54pm)
cpu.pro (288 Byte - 5 times downloaded - Last download: Jul 10th 2008, 7:33am)
cpuload.cpp (7.43 kB - 11 times downloaded - Last download: Jul 1st 2008, 6:31pm)

Lesiok

Beginner

Posts: 4

5

Tuesday, May 13th 2008, 9:18am

The buffer created in line

	Source code
1	file = new char(flen);

is to small (one character) to reading data in line

	Source code
1	fgets(file, flen+1 , fp);

Change this line to

	Source code
1	file = new char(flen+1);

This post has been edited 1 times, last edit by "Lesiok" (May 13th 2008, 9:19am)

srinivasj

Beginner

Posts: 17

6

Tuesday, May 13th 2008, 9:30am

Even after modifing the allocation of memory it was segementing.

Let me explain my problem:

I have tried to create a sample application only for reading the data from the /proc/stat file and plotting the cpudata values with respact to the timefactor.
The application was working fine till yesterday. But from yesterday what I have I have observed is the apllication is segmenting after 30-32 timerevents(total timer events are 12

. It was segementing while trying to open the /proc/stat file .

Following is the snippet of the segmentation message :
/**********************************************************************************/
*** glibc detected *** ./cpu: malloc(): memory corruption: 0x0000000000669a40 *** ======= Backtrace: ========= /lib64/libc.so.6[0x36c4c6f0e4] /lib64/libc.so.6(__libc_malloc+0x7d)[0x36c4c7086d]
/lib64/libc.so.6[0x36c4c5ecda]
./cpu(_ZN7QWidget11qt_propertyEiiP8QVariant+0xef4)[0x4059ac]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN7QObject5eventEP6QEvent+0x66)[0x3e79560ff6]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN7QWidget5eventEP6QEvent+0x2

[0x3e79598518]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0x85)[0x3e795007d5]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0xa4)[0x3e79501ca4]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop14activateTimersEv+0x21c)[0x3e794f5bbc]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop13processEventsEj+0x4e1)[0x3e794af351]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop9enterLoopEv+0x41)[0x3e79517f91]
/usr/lib64/qt-3.3/lib/libqt-mt.so.3(_ZN10QEventLoop4execEv+0x22)[0x3e79517e72]
./cpu(_ZN7QWidget5closeEb+0x24b)[0x405523]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x36c4c1da44]
./cpu(_ZN7QWidget5closeEb+0xc1)[0x405399]
======= Memory map: ========
00400000-00407000 r-xp 00000000 08:03 622657 /DEMO/cpu/cpu
00607000-00608000 rw-p 00007000 08:03 622657 /DEMO/cpu/cpu
00608000-006aa000 rw-p 00608000 00:00 0 [heap]
36c4800000-36c481a000 r-xp 00000000 08:03 98887 /lib64/ld-2.5.so
36c4a19000-36c4a1a000 r--p 00019000 08:03 98887 /lib64/ld-2.5.so
/************************************************************************************************************************/
I have tried to find out why it was segmenting at the fopen call using strace, what I could find out is, the application is trying to open dev/tty/ file and segementing

Segmentation Message Sniipet:
/***********************************************************************************************************************************************/
write(1, "ThE TIMER event is called:\n", 27ThE TIMER event is called:
) = 27
write(1, "Before the fopen call:\n", 23Before the fopen call:
) = 23
open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 6 writev(6, [{"*** glibc detected *** ", 23}, {"./cpu", 5}, {": ", 2}, {"malloc(): memory corruption", 27}, {": 0x", 4}, {"0000000000673750", 16}, {" ***\n", 5}], 7*** glibc detected *** ./cpu: malloc(): memory corruption: 0x0000000000673750 ***
) = 82
mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2aaaae558000
munmap(0x2aaaae558000, 27951104) = 0
munmap(0x2aaab4000000, 39157760) = 0
mprotect(0x2aaab0000000, 135168, PROT_READ|PROT_WRITE) = 0 futex(0x36c4f4bf20, FUTEX_WAKE, 2147483647) = 0 futex(0x36d440cdd0, FUTEX_WAKE, 2147483647) = 0 write(6, "======= Backtrace: =========\n", 29======= Backtrace: =========
) = 29
writev(6, [{"/lib64/libc.so.6", 16}, {"[0x", 3}, {"36c4c6f0e4", 10}, {"]\n", 2}], 4/lib64/libc.so.6[0x36c4c6f0e4] /**************************************************************************************************************************************************/

srinivasj has attached the following file:

cpuload.cpp (7.75 kB - 6 times downloaded - Last download: Jun 6th 2008, 11:25pm)

Nicolas SOUCHON

Professional

Posts: 954

7

Tuesday, May 13th 2008, 9:36am

supressed

Nicolas

This post has been edited 1 times, last edit by "Nicolas SOUCHON" (May 13th 2008, 9:38am)

stinos

Intermediate

Posts: 229

8

Tuesday, May 13th 2008, 9:37am

well on first sight, you're doing a buncj of operation on the pointer 'file', without properly checking if it stays within bounds. you also never delete the memory. can't tell if that's the problem though, not on unix atm.

madinsjamania

srinivasj

Beginner

Posts: 17

9

Tuesday, May 13th 2008, 9:39am

Yaa . I understand that, But is there fault im my code where I am corrupting memory ?

Can you help me how to debug this issue?

srinivasj

Beginner

Posts: 17

10

Tuesday, May 13th 2008, 9:43am

So how do you want to check for the bound?

stinos

Intermediate

Posts: 229

11

Tuesday, May 13th 2008, 10:51am

Quoted

Originally posted by srinivasj
So how do you want to check for the bound?

by using a string class instead of char*; since you're using qt anyway, why not implement everything with QFile/QString/QTExtStream.

or else, at least check what you're doing.
example:

file = new char[ len + 1 ];
file = file+len1+1;

problem 1: you modify file so you cannot delete if afterwards; so to solve mem leak:

file = new char[ len + 1 ];
char* filePtr = file+len1+1;
delete file;

problem 2: when filePtr > file + len + 1 you're accessing memory that's not yours. get around by checking that condition and do something appropriate.

madinsjamania

Nicolas SOUCHON

Professional

Posts: 954

12

Tuesday, May 13th 2008, 11:47am

try to launch your app with kdbg/gdb
with a breakpoint at QApplication a( argc, argv );

when the program is halted, verify the output of
cat /proc/thPidOfYourApp/maps

Nicolas

srinivasj

Beginner

Posts: 17

13

Tuesday, May 13th 2008, 11:54am

This is the output of the at the time of debugging .

260 SysInfo *sysinfo = new SysInfo;
(gdb) cat /proc/thPidOfYourApp/maps
catch requires an event

I have tried to do catof the file seperatly on a terminal .

The output was:

cat: /proc/thPidOfYourApp/maps: No such file or directory

Nicolas SOUCHON

Professional

Posts: 954

14

Tuesday, May 13th 2008, 12:22pm

cat /proc/thePidOfYourApp/maps
is to be executed in a shell
thePidOfYourApp is to be replaced by the pid of your running program

example: cat /pro/12456/maps

Nicolas

This post has been edited 1 times, last edit by "Nicolas SOUCHON" (May 13th 2008, 12:23pm)

srinivasj

Beginner

Posts: 17

15

Tuesday, May 13th 2008, 1:04pm

I am really very sorry.
I did not read the last reply properly

This is the output:

00400000-006d4000 r-xp 00000000 08:03 3031813 /usr/bin/gdb
008d4000-008e3000 rw-p 002d4000 08:03 3031813 /usr/bin/gdb
008e3000-00900000 rw-p 008e3000 00:00 0
00ae2000-00afa000 rw-p 002e2000 08:03 3031813 /usr/bin/gdb
00afa000-02155000 rw-p 00afa000 00:00 0 [heap]
36c4800000-36c481a000 r-xp 00000000 08:03 98887 /lib64/ld-2.5.so
36c4a19000-36c4a1a000 r--p 00019000 08:03 98887 /lib64/ld-2.5.so
36c4a1a000-36c4a1b000 rw-p 0001a000 08:03 98887 /lib64/ld-2.5.so
36c4c00000-36c4d44000 r-xp 00000000 08:03 98888 /lib64/libc-2.5.so
36c4d44000-36c4f44000 ---p 00144000 08:03 98888 /lib64/libc-2.5.so
36c4f44000-36c4f48000 r--p 00144000 08:03 98888 /lib64/libc-2.5.so
36c4f48000-36c4f49000 rw-p 00148000 08:03 98888 /lib64/libc-2.5.so
36c4f49000-36c4f4e000 rw-p 36c4f49000 00:00 0
36c5000000-36c5003000 r-xp 00000000 08:03 98539 /lib64/libdl-2.5.so
36c5003000-36c5202000 ---p 00003000 08:03 98539 /lib64/libdl-2.5.so
36c5202000-36c5203000 r--p 00002000 08:03 98539 /lib64/libdl-2.5.so
36c5203000-36c5204000 rw-p 00003000 08:03 98539 /lib64/libdl-2.5.so
36c5400000-36c5482000 r-xp 00000000 08:03 98895 /lib64/libm-2.5.so
36c5482000-36c5681000 ---p 00082000 08:03 98895 /lib64/libm-2.5.so
36c5681000-36c5682000 r--p 00081000 08:03 98895 /lib64/libm-2.5.so
36c5682000-36c5683000 rw-p 00082000 08:03 98895 /lib64/libm-2.5.so
36d7600000-36d764f000 r-xp 00000000 08:03 3098922 /usr/lib64/libncurses.so.5.5
36d764f000-36d784e000 ---p 0004f000 08:03 3098922 /usr/lib64/libncurses.so.5.5
36d784e000-36d785c000 rw-p 0004e000 08:03 3098922 /usr/lib64/libncurses.so.5.5
36d785c000-36d785d000 rw-p 36d785c000 00:00 0
2aaaaaaab000-2aaaaaaac000 rw-p 2aaaaaaab000 00:00 0
2aaaaaac0000-2aaaaaac3000 rw-p 2aaaaaac0000 00:00 0
2aaaaaac3000-2aaaadfc2000 r--p 00000000 08:03 3589751 /usr/lib/locale/locale-archive
2aaaadfc2000-2aaaadfc9000 r--s 00000000 08:03 3621699 /usr/lib64/gconv/gconv-modules.cache
2aaaadfc9000-2aaaadfcb000 rw-p 2aaaadfc9000 00:00 0
2aaaadfd6000-2aaaadfdc000 r-xp 00000000 08:03 98456 /lib64/libthread_db-1.0.so
2aaaadfdc000-2aaaae1db000 ---p 00006000 08:03 98456 /lib64/libthread_db-1.0.so
2aaaae1db000-2aaaae1dc000 r--p 00005000 08:03 98456 /lib64/libthread_db-1.0.so
2aaaae1dc000-2aaaae1dd000 rw-p 00006000 08:03 98456 /lib64/libthread_db-1.0.so
2aaaae205000-2aaaae2aa000 rw-p 2aaaae205000 00:00 0
2aaaae3c1000-2aaaaecdf000 rw-p 2aaaae3c1000 00:00 0
7fffbd0a3000-7fffbd0b8000 rw-p 7fffbd0a3000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]

Sorry for troubling you

Nicolas SOUCHON

Professional

Posts: 954

16

Tuesday, May 13th 2008, 1:13pm

this is the output for the process of gdb,
not for the process of your program

Nicolas

Nicolas SOUCHON

Professional

Posts: 954

17

Tuesday, May 13th 2008, 3:46pm

Quoted

Originally posted by srinivasj
... But is there fault im my code where I am corrupting memory ?

in reading the file
here is a more simple way to do it

Source code

FILE   * file;
    char     buffer [2048];
    char   * elem;
    int      i;
    double   cpudata[8];
    if( !( file = fopen( "/proc/stat", "r" )) )
    {
        qDebug( "Error opening stat file" );
        return;
    }
    if( fgets( buffer, sizeof(buffer), file ) )
    {
        for( elem = strtok( buffer, " " ), i = -1; elem && (i < 8); elem = strtok( NULL, " " ), i++ )
        {
            if( i < 0 ) continue; // skip the header of the line
            cpudata[i] = atof( elem );
        }
    }
    fclose( file );

Nicolas

This post has been edited 4 times, last edit by "Nicolas SOUCHON" (May 13th 2008, 5:08pm)

QtForum.org