LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 05-02-2012, 06:29 AM   #1
lwoh
LQ Newbie
 
Registered: Feb 2012
Posts: 4

Rep: Reputation: Disabled
glibc Issue


Hi,

I have an ESLQ/C program that shows the error on console below during runtime. It is an executable that reads and processes text files by using some user-defined file processing functions. I have tried Valgrind and Splint. Valgrind shows two errors at the line when db connection is established, while Splint shows error like "memory not freed before returned" which i did edit the code to solve it, but... the same glibc error still occurs during runtime. Any idea how to debug and trace such errors?

NOTE:
Although the backtrace shows the similar function name everytime this error happens but the error displayed after "*** glibc detected *** SAM-UPD:" is not the same everytime.
eg.,
-bash-3.2$ *** glibc detected *** SAM-UPD: free(): invalid pointer
-bash-3.2$ *** glibc detected *** SAM-UPD: double free or corruption (!prev): 0x00000
-bash-3.2$ *** glibc detected *** SAM-UPD: corrupted double-linked list: 0x0000000006cfb7a0


-bash-3.2$ *** glibc detected *** SAM-UPD: double free or corruption (!prev): 0x
000000000cd06570 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3a1e27245f]
/lib64/libc.so.6(cfree+0x4b)[0x3a1e2728bb]
/lib64/libc.so.6(fclose+0x14b)[0x3a1e260eab]
/home/saudit/SAM360/sam/lib/libscbci.so(bad_close+0xda)[0x2aaf0fad04ee]
/home/saudit/SAM360/sam/lib/libscbci.so(proc_file+0x8a4)[0x2aaf0fad14b8]
/home/saudit/SAM360/sam/lib/libscbci.so(do_work+0x99)[0x2aaf0fad0b8c]
/home/saudit/SAM360/sam/lib/libscbci.so(process+0x28c)[0x2aaf0fad38d6]
/home/saudit/SAM360/sam/lib/libscbci.so(init_proc+0x4ba)[0x2aaf0fad362a]
SAM-UPD[0x408835]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3a1e21d994]
SAM-UPD[0x407939]
======= Memory map: ========
00400000-0051d000 r-xp 00000000 fd:02 131081 /home/s
audit/SAM360/sam/bin/samupd.apis
0071c000-00744000 rw-p 0011c000 fd:02 131081 /home/s
audit/SAM360/sam/bin/samupd.apis
00744000-019df000 rw-p 00744000 00:00 0
0cc74000-0cd17000 rw-p 0cc74000 00:00 0 [heap]
3a1de00000-3a1de1c000 r-xp 00000000 08:03 64095 /lib64/
ld-2.5.so
3a1e01b000-3a1e01c000 r--p 0001b000 08:03 64095 /lib64/
ld-2.5.so
3a1e01c000-3a1e01d000 rw-p 0001c000 08:03 64095 /lib64/
ld-2.5.so
3a1e200000-3a1e34e000 r-xp 00000000 08:03 64111 /lib64/
libc-2.5.so
3a1e34e000-3a1e54e000 ---p 0014e000 08:03 64111 /lib64/
libc-2.5.so
3a1e54e000-3a1e552000 r--p 0014e000 08:03 64111 /lib64/
libc-2.5.so
3a1e552000-3a1e553000 rw-p 00152000 08:03 64111 /lib64/
libc-2.5.so
3a1e553000-3a1e558000 rw-p 3a1e553000 00:00 0
3a1e600000-3a1e602000 r-xp 00000000 08:03 64112 /lib64/
libdl-2.5.so
3a1e602000-3a1e802000 ---p 00002000 08:03 64112 /lib64/
libdl-2.5.so
3a1e802000-3a1e803000 r--p 00002000 08:03 64112 /lib64/
libdl-2.5.so
3a1e803000-3a1e804000 rw-p 00003000 08:03 64112 /lib64/
libdl-2.5.so
3a1f200000-3a1f216000 r-xp 00000000 08:03 64118 /lib64/
libpthread-2.5.so
3a1f216000-3a1f415000 ---p 00016000 08:03 64118 /lib64/
libpthread-2.5.so
3a1f415000-3a1f416000 r--p 00015000 08:03 64118 /lib64/
libpthread-2.5.so
3a1f416000-3a1f417000 rw-p 00016000 08:03 64118 /lib64/
libpthread-2.5.so
3a1f417000-3a1f41b000 rw-p 3a1f417000 00:00 0
3a1f600000-3a1f682000 r-xp 00000000 08:03 64122 /lib64/
libm-2.5.so
3a1f682000-3a1f881000 ---p 00082000 08:03 64122 /lib64/
libm-2.5.so
3a1f881000-3a1f882000 r--p 00081000 08:03 64122 /lib64/
libm-2.5.so
3a1f882000-3a1f883000 rw-p 00082000 08:03 64122 /lib64/
libm-2.5.so
3a20200000-3a20209000 r-xp 00000000 08:03 63867 /lib64/
libcrypt-2.5.so
3a20209000-3a20408000 ---p 00009000 08:03 63867 /lib64/
libcrypt-2.5.so
3a20408000-3a20409000 r--p 00008000 08:03 63867 /lib64/
libcrypt-2.5.so
3a20409000-3a2040a000 rw-p 00009000 08:03 63867 /lib64/
libcrypt-2.5.so
3a2040a000-3a20438000 rw-p 3a2040a000 00:00 0
3a20a00000-3a20a11000 r-xp 00000000 08:03 64031 /lib64/
libresolv-2.5.so
3a20a11000-3a20c11000 ---p 00011000 08:03 64031 /lib64/
libresolv-2.5.so
3a20c11000-3a20c12000 r--p 00011000 08:03 64031 /lib64/
libresolv-2.5.so
3a20c12000-3a20c13000 rw-p 00012000 08:03 64031 /lib64/
libresolv-2.5.so
3a20c13000-3a20c15000 rw-p 3a20c13000 00:00 0
2aaf0faca000-2aaf0facc000 rw-p 2aaf0faca000 00:00 0
2aaf0facc000-2aaf0fad9000 r-xp 00000000 fd:02 229390 /home/s
audit/SAM360/sam/lib/libscbci.so
2aaf0fad9000-2aaf0fcd8000 ---p 0000d000 fd:02 229390 /home/s
audi
 
Old 05-02-2012, 02:44 PM   #2
Snark1994
Senior Member
 
Registered: Sep 2010
Distribution: Debian
Posts: 1,632
Blog Entries: 3

Rep: Reputation: 346Reputation: 346Reputation: 346Reputation: 346
Easiest way I've found is to put printf() messages in your code, and move them until you know which line is causing the error (e.g. put one at the start. If you run it, the message should print, and then the error should trigger. Keep moving the printf() through the code until the error comes first, and then you should know which line has the error). You then need to work backwards, and see where else you have freed that pointer.

Obviously, this approach's success will vary with the complexity of your code. If it's too complicated, perhaps try looking at gdb or other such tools.
 
Old 05-07-2012, 06:10 AM   #3
lwoh
LQ Newbie
 
Registered: Feb 2012
Posts: 4

Original Poster
Rep: Reputation: Disabled
printf doesn't seem to help much as i cannot simulate this issue consistently and this is an existing program coded according to a framework done internally in the company long long time ago. No one can 100 per cent tell how it works.

Can i debug based on the functions displayed under "Backtrace" ? does "Backtrace" provide relevant and useful information ? How can i debug based on "Backtrace" ?
 
Old 05-07-2012, 06:15 AM   #4
dwhitney67
Senior Member
 
Registered: Jun 2006
Location: Maryland
Distribution: Kubuntu, Fedora, RHEL
Posts: 1,541

Rep: Reputation: 335Reputation: 335Reputation: 335Reputation: 335
Use valgrind. Make sure your program is compiled with the -g option so that symbolic information is present.
 
Old 10-27-2012, 08:46 AM   #5
lwoh
LQ Newbie
 
Registered: Feb 2012
Posts: 4

Original Poster
Rep: Reputation: Disabled
This has been solved with GDB. It is found that there is a checking on whether a file descriptor is NULL/has a value before fclose() is executed. However, fclose() does not nullify the file descriptor and it results in the same file descriptor being closed for multiple times.Thanks all for the help.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Need further help understanding GLIBC issue dwhitney67 Programming 5 09-12-2011 12:01 PM
[SOLVED] glibc 2.14 compilation issue kapsikum Programming 11 08-25-2011 06:18 AM
glibc Dependency Issue siwelb Red Hat 2 09-11-2009 02:38 PM
Firefox/Thunderbird not starting - glibc issue? rpedrica Slackware 3 04-03-2009 09:22 AM
glibc.so.6 issue on RH Enterprise Linux 4 :( Ofers Red Hat 3 04-18-2007 06:00 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 12:37 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration