program got random crash on LINUX, big memory issue? LINUX bug?
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
a operating system that is missing 3 YEARS of security updates
running the 32 bit 4.8 on new 64 bit hardware will well , not work well
the gcc flag would be ( m32 or m64 )
but autotools should auto detect that and auto set it
you would need a 64 bit version of cent for using 64 bit memory registers
and 4.8 and 4.9 are both DEAD
this is a quote for the "place holder" on the cent os mirrors
Quote:
This directory (and version of CentOS) is depreciated. For normal users,
you should use /4/ and not /4.8/ in your path. Please see this FAQ
concerning the CentOS release scheme:
RHEL 5.8 is 2 years old and version 5 is not receiving any substantial updates, it's in the phase where they offer discretionary releases; meaning they're supporting it per their discretion but not really working extensively at it and if they find something difficult to integrate into that release, they do not include it.
RHEL main releases are up to 7 as of a year ago.
You went from a very old CentOS to an old RHEL.
That's not helping really.
If you actually own RHEL 5.8, ask RedHat for support on this matter.
Thanks @rtmistler, I will try.
the binary was built on 32bit
Linux xxx 2.6.16.60-0.21-default #1 Tue May 6 12:41:02 UTC 2008 i686 i686 i386 GNU/Linux
and running on 64 bit
Linux 2.6.18-308.el5
Thanks @rtmistler, I will try.
the binary was built on 32bit
Linux xxx 2.6.16.60-0.21-default #1 Tue May 6 12:41:02 UTC 2008 i686 i686 i386 GNU/Linux
and running on 64 bit
Linux 2.6.18-308.el5
So ... you're compiling this program? Or have compiled it?
If you have the source, build it on the actual target system you intend to run it on. That likely will solve almost all of these problems.
Use ulimit -c unlimited to cause core file dumps
When you compile, use -ggdb to generate a GDB debug capable image
If/When it next crashes given those prior recommendations of ulimit and GDB compile flag, you can do two or more things:
Analyze the core file using GDB
Debug the program by running it out of the debugger
Editing the program to add lots of debug showing progress as it loads up and begins, or operates
rtmistler, yes, I compiled it. and I have done all these steps you mentioned, ulimited, gdb bt, strace.
The core dump and strace file was showing that it crashed on kernel socket layer to receive a packet.
rtmistler, yes, I compiled it. and I have done all these steps you mentioned, ulimited, gdb bt, strace.
The core dump and strace file was showing that it crashed on kernel socket layer to receive a packet.
I see two instances of segmentation violations, but no backtrace. You can run this program in GDB and wait for it to SEGV and then do backtrace to see where the program backtrace. Seeing only the list of system calls via strace doesn't get you much here. For instance if you have a NULL pointer, then of course it's going to fail in a system call, but that doesn't mean it had anything to do with that particular system call.
rtmistler, the backtrace is as below:
Program terminated with signal 11, Segmentation fault.
#0 0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x003c5df0 in ?? ()
#2 0x57440300 in ?? ()
#3 0x0000000b in ?? ()
#4 0xffe1003c in ?? ()
#5 0x56c53503 in ?? ()
#6 0x0000000b in ?? ()
#7 0xffe0ff60 in ?? ()
#8 0x56ebf98a in ?? ()
#9 0x00000000 in ?? ()
Nothing more to that backtrace? Does it go below #9? Or has this not been properly compiled using -ggdb flag?
For instance here's an example of code containing an obvious segment violation and the result of a debug session:
Code:
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
int *bad_addr = NULL;
*bad_addr = 12345;
return 0;
}
Code:
testcode$ gcc -ggdb -o segv segv.c ## Compilation example using -ggdb flag, if you don't do this then you're not going to see symbols and thus backtrace isn't going to get you any useful information
testcode$ gdb segv
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from ~testcode/segv...done. ## Note here that when loading GDB reads the symbols from the binary image, this needs to happen otherwise you see nothing of merit
(gdb) r
Starting program: ~testcode/segv
Program received signal SIGSEGV, Segmentation fault.
0x080483c4 in main (argc=1, argv=0xbffff3a4) at segv.c:8
8 *bad_addr = 12345;
(gdb) bt ## Backtrace here is very small, but shows that in segv.c at line 8 was the last program execution point
#0 0x080483c4 in main (argc=1, argv=0xbffff3a4) at segv.c:8
(gdb) p bad_addr
$1 = (int *) 0x0 ## And here's the reason why the segment violation occurred
(gdb)
In short, I feel that your backtrace should show symbols. Are you not seeing the symbols when you start GDB?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
