Core Dump - non-existing file - c

I've made a program with a segmentation fault and i want to get the core dump file but it seems that the file is not on the current directory. I've read and follow these instructions:
core dumped - but core file is not in current directory?
but I'm still unable to get the core file.
I've tried this:
ulimit -c unlimited
ulimit -S -c unlimited
I've also edited /etc/security/limits.conf the line:
* soft core 10000
(it was 0 the default value)
And as my system runs apport so I've searched /var/crash and the file I wanted (that should've generated) wasn't in there.
More useful information:
$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c
So what did I miss? I still don't get the core file after the segmentation fault or if I do I don't know where he is going to.

Related

Compiling perl >5.10 on AIX version 5.3

I've been compiling OpenSSL (and thus Perl >5.10, as it is a dependency) on multiple platforms. I've managed to get 1.1.0b compiled on every single platform except AIX, which I can't even compile Perl. I've tried several versions and looked at the documentation Perl provides online. From what I can tell, it suggests version 5.12.2.
When I attempt to compile version 5.12.2,
I take the following from the documentation, and fill in a few local system variables, such as using XLC rv7.
export OBJECT_MODE=64
./Configure \
-d \
-Dcc=/usr/vac/bin/xlc_r7 \
-Duseshrplib \
-Duse64bitall \
-Dprefix=`pwd`/../PERL
Then I attempt to make as prompted, and get the following error:
/usr/vac/bin/xlc_r7 -q64 -o miniperl -brtl -bdynamic -L/usr/local/lib -b64 gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o miniperlmain.o opmini.o perlmini.o -lbind -lnsl -ldl -lld -lm -lcrypt -lc
LIBPATH=.../perl-5.12.2 ./miniperl -w -Ilib -MExporter -e '<?>' || make minitest
LIBPATH=.../perl-5.12.2 ./miniperl -Ilib autodoc.pl
/usr/bin/ln -s perl5122delta.pod pod/perldelta.pod
LIBPATH=.../perl-5.12.2 ./miniperl -Ilib -Icpan/Cwd -Icpan/Cwd/lib pod/perlmodlib.PL -q
readdir(./../../../../..): Bad file number at lib/FindBin.pm line 116
stat(/pod/): No such file or directory at lib/FindBin.pm line 197
stat(/pod/): No such file or directory at lib/FindBin.pm line 200
Use of chdir('') or chdir(undef) as chdir() is deprecated at pod/perlmodlib.PL line 9.
No such file or directory at pod/perlmodlib.PL line 19.
make: The error code from the last command is 2.
Taking a look at pod/perlmodlib.PL, we see the following:
# MANIFEST itself is Unix style filenames, so we have to assume that Unix style
# filenames will work.
open (MANIFEST, "../MANIFEST") or die $!;
In my desperation I tried to hack it up and avoid writing to the manifest, but then I get this issue:
Creating Makefile.PL in cpan/Archive-Extract for Archive::Extract
Running Makefile.PL in cpan/Archive-Extract
../../miniperl Makefile.PL INSTALLDIRS=perl INSTALLMAN1DIR=none INSTALLMAN3DIR=none PERL_CORE=1 LIBPERL_A=libperl.a
readdir(./../../../../../../..): No such file or directory at ../../lib/File/Find.pm line 610
Use of chdir('') or chdir(undef) as chdir() is deprecated at ../../lib/File/Find.pm line 773.
readdir(./../../..): No such file or directory at ../../cpan/Cwd/lib/File/Spec/Unix.pm line 483
Could not open 'lib/Archive/Extract.pm': No such file or directory at ../../cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm line 2588.
512 from cpan/Archive-Extract's Makefile.PL at make_ext.pl line 390.
Warning: No Makefile!
make: Cannot find a rule to create target config from dependencies.
Stop.
make config PERL_CORE=1 LIBPERL_A=libperl.a failed, continuing anyway...
Making all in cpan/Archive-Extract
make all PERL_CORE=1 LIBPERL_A=libperl.a
make: Cannot find a rule to create target all from dependencies.
Stop.
Unsuccessful make(cpan/Archive-Extract): code=512 at make_ext.pl line 449.
make: The error code from the last command is 2.
The frequency of errors makes me feel like perhaps I don't have something configured right...
My next thought was to try the most updated version, which at the time of writing is 5.24. Using the same configuration and attempting to make I get the following issue:
Can't locate strict.pm in #INC (you may need to install the strict module) (#INC contains: /cpan/AutoLoader/lib /dist/Carp/lib /dist/PathTools /dist/PathTools/lib /cpan/ExtUtils-Install/lib /cpan/ExtUtils-MakeMaker/lib /cpan/ExtUtils-Manifest/lib /cpan/File-Path/lib /ext/re /dist/Term-ReadLine/lib /dist/Exporter/lib /ext/File-Find/lib /cpan/Text-Tabs/lib /dist/constant/lib /cpan/version/lib /lib .) at autodoc.pl line 25.
BEGIN failed--compilation aborted at autodoc.pl line 25.
make: The error code from the last command is 2.
Which I know from other compilations means I need to edit the PERL5LIB variable.
If I keep adding all the modules to the path:
export PERL5LIB=`pwd`/dist/Exporter/lib:$PERL5LIB
export PERL5LIB=`pwd`/cpan/Text-Tabs/lib:$PERL5LIB
export PERL5LIB=`pwd`/ext/re:$PERL5LIB
export PERL5LIB=`pwd`/dist/constant/lib:$PERL5LIB
export PERL5LIB=`pwd`/cpan/ExtUtils-MakeMaker/lib:$PERL5LIB
export PERL5LIB=`pwd`/dist/Carp/lib:$PERL5LIB
export PERL5LIB=`pwd`/cpan/File-Path/lib:$PERL5LIB
export PERL5LIB=`pwd`/dist/PathTools:$PERL5LIB
export PERL5LIB=`pwd`/dist/PathTools/lib:$PERL5LIB
export PERL5LIB=`pwd`/ext/File-Find/lib:$PERL5LIB
Even so, I'll still get an error for a module that isn't even present in the 5.24.0 source!
Can't locate ExtUtils/MakeMaker/version/vpp.pm in #INC (you may need to install the ExtUtils::MakeMaker::version::vpp module) (#INC contains: <removed from post>) at (eval 2) line 2.
BEGIN failed--compilation aborted at (eval 2) line 2.
Compilation failed in require at .../perl-5.24.0/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 10.
BEGIN failed--compilation aborted at .../perl-5.24.0/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm line 10.
Compilation failed in require at Makefile.PL line 7.
BEGIN failed--compilation aborted at Makefile.PL line 7.
Unsuccessful Makefile.PL(cpan/Archive-Tar): code=512 at make_ext.pl line 517.
make: The error code from the last command is 2.
I have MakeMaker, but the 5.24 version does not contain vpp.pm! Again, in desperation I attempted to put it in there from a different source, and I get this error:
LIBPATH=.../perl-5.24.0 ./miniperl -Ilib make_ext.pl cpan/Archive-Tar/pm_to_blib MAKE="make" LIBPERL_A=libperl.a
readdir(./../../../../../../..): No such file or directory at .../perl-5.24.0/ext/File-Find/lib/File/Find.pm line 142.
Can't cd to : No such file or directory
Unsuccessful Makefile.PL(cpan/Archive-Tar): code=512 at make_ext.pl line 517.
make: The error code from the last command is 2.
All of this makes me feel like perhaps I'm not configuring something right... Can anyone with some experience help me out with some cut and dry installation instructions for Perl on AIX? I'd be super grateful. Thanks!
Below is some information about my system:
> prtconf
System Model: IBM,8231-E1D
Machine Serial Number: Not Available
Processor Type: Not Available
Processor Implementation Mode: POWER 7
Processor Version: PV_7_Compat
Number Of Processors: 0
Processor Clock Speed: Not Available
CPU Type: 64-bit
Kernel Type: 64-bit
Memory Size: 10240 MB
Good Memory Size: Not Available
Platform Firmware level: Not Available
Firmware Version: IBM,AL770_092
Console Login: disable
Auto Restart: true
Full Core: false
I pull down and compile openssh and openssl frequently. I use gcc and no real magic that I can recall.
Here is my script to build it. I don't know which perl is native to AIX but it seems to work for me.
https://github.com/pedz/aix-build-scripts/blob/master/build-scripts/build-openssl

Forcing program to create coredump on freebsd

In my project I added a new module and now my process is being terminated by signal 11 .
I want to track and understand the problem but no coredump file is generated by freebsd.
I set sysctl like :
sysctl -a | grep core
kern.corefile: /usr/core
kern.nodump_coredump: 1
kern.coredump: 1
kern.sugid_coredump: 1
debug.elf64_legacy_coredump: 1
debug.elf32_legacy_coredump: 1
I also set ulimit -c unlimited
From my code I removed all code about signal like "sigaction(SIGTERM, &signal, &signal_old);"
for not preventing kernel to generate coredump.
Why I can't see any coredump still ? What I am missing ?
Also are there any method forcing a program which run on freebsd to create coredump an equivalent to do_coredump() in linux?
The problem is in:
kern.corefile: /usr/core
Something like the following should help:
sysctl -w kern.corefile = "%N.core"
If I recall correctly, kern.corefile is the complete name of the resulting corefile, not the directory in which it should be placed. It also needs to be writable by the user running the process. /usr/core looks like a directory and/or a location writable only by root.
kern.nodump_coredump: 1 also looks suspicious.I don't remember that sysctl existing in the last version of FreeBSD I used, but it looks like it's intended to disable core dumps. Try setting it to 0.

C script running as cron giving permission denied error

I have a .c file compiled and would like to run via a cron job but I end up getting this error:
/bin/sh: /usr/local/bin/get1Receive.c: Permission denied.
What is causing this error and how do I fix it?
Should I be running the .c file in cron or a different compiled file?
Results from /tmp/myvars
GROUPS=()
HOME=/root
HOSTNAME=capture
HOSTTYPE=x86_64
IFS='
'
LOGNAME=root
MACHTYPE=x86_64-redhat-linux-gnu
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/bin:/bin
POSIXLY_CORRECT=y
PPID=11086
PS4='+ '
PWD=/root
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments:posix
SHLVL=1
TERM=dumb
UID=0
USER=root
_=/bin/sh
Results from file get1Receive.c
file get1Receive.c
get1Receive.c: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
Snippet of codes.
sprintf(queryBuf1,"SELECT ipDest, macDest,portDest, sum(totalBits) FROM dataReceive WHERE timeStampID between '%s' And '%s' GROUP BY ipDest, macDest, portDest ",buff1,buff2);
printf("\nQuery receive %s",queryBuf1);
if(mysql_query(localConn, queryBuf1))
{
//fprintf(stderr, "%s\n", mysql_error(localConn));
printf("Error in first query of select %s\n",mysql_error(localConn));
exit(1);
}
localRes1 = mysql_store_result(localConn);
int num_fields = mysql_num_fields(localRes1);
printf("\nNumf of fields : %d",num_fields);
printf("\nNof of row : %lu",mysql_num_rows(localRes1));
If the output of this command:
file get1Receive1.c
shows that file name to be a valid executable that part is very unusual, but okay.
Assuming you are using biz14 (or your real username's ) crontab try this:
use the command crontab -e to create this line in your crontab:
* * * * * set > /tmp/myvars
Wait a few minutes, go back into crontab -e and delete that entry.
Use the set command from the command line to see what variables and aliases exist.
Compare that with that you see in /tmp/myvars You have to change how your C code executes by changing the variables and aliases the cron job runs with.
If you are running the cron job in someone else's crontab, then you have a bigger problem. Check file permissions on get1Receive1.c. and the directory it lives in. That other user (the one who wons the crontab) has to have permissions set on your directory and get1Receive1.c so the job can run.
Example crontab entry:
0 10 * * 1-5 /path/to/get1Receive1.c > /tmp/outputfile
Read /tmp/outputfile to see what you got. You are using printf in your code. printf only writes to the controlling terminal. There is no controlling terminal, so redirect the printf stuff to a file.
Last effort on this problem:
Check return codes on EVERYTHING. All C functions like fread(), any db function, etc. If a return code gives a fail response ( these are different for different function calls) then report the error number the line number and function - gcc provides LINE and func. Example:
printf("error on line %d in my code %s, error message =%s\n", __LINE__, __func__, [string of error message]);
If you do not check return codes you are writing very poor C code.
CHECK return codes, please, now!
Permission wise you could have two issues.
1. The 'c' file's permissions don't allow who you are running it as to run it.
2. You are running the cron with a script which doesn't have permissions.
Here's a helpful post: How to give permission for the cron job file?
The fact that you are running a 'c' file and referring to it as a script makes me think you're using C shell and not writing it as a C language program which would need to be compiled and have the generated executable run by the cron. If you're not using gcc or have never called gcc on your 'C' script then it's not C and call it C shell to avoid confusion.

Phusion Passenger got an g++: Internal error

I have successfully installed the paggenger gem using following command
rvmsuo gem install passenger
After that when I am tried to install passenger module for apache2 using following command
rvmsudo passenger-install-apache2-module
Installation start, all dependencies are checked and passed, and at time of compilation, i got following error,
g++ ApplicationPoolServerExecutable.cpp System.o Utils.o Logging.o -o
ApplicationPoolServerExecutable -I.. -D_REENTRANT -g -DPASSENGER_DEBUG -Wall -
I/usr/local/include -DPASSENGER_DEBUG ../boost/src/libboost_thread.a -lpthread
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see <an url goes here>
rake aborted!
Command failed with status (1): [g++ ApplicationPoolServerExecutable.cpp Sy...]
/opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/passenger-
2.0.6/Rakefile:161
I have check the apache error log but, i did't got any clue.
If you don't have enough memory, you may be able to make some temporary adjustments on your Linux machine.
# Add 2GB of swap space
dd if=/dev/zero of=/swap bs=1k count=2048k
mkswap /swap
swapon /swap
# Set overcommit to 100
sysctl vm.overcommit_ratio=100
# Set swappiness (encourages more swapping)
sysctl vm.swappiness=50
After this, retry. If all is well, a simple reboot should undo these changes or, of course, you can set the sysctl's back to their original values and remove the swap. Keep in mind a reboot won't free the disk space, you'll need to rm /swap after reboot.
I was trying to run it in a virtual machine which consist of 256 mb ram. When i have allocate more memory (1 gb) to that virtual machine, the problem solved .

Core Dump is is not working

When I run programs with segfaults I get an error message Segmentation fault: 11. For some reason, I'm not getting the (core dumped) message. I tried running the shell command ulimit -c unlimited, but I still get the same error and it doesn't say core dumped. I'm new to GDB so I tried it with a simple program:
/* coredump.c */
#include <stdio.h>
int main (void) {
int *point = NULL;
*point = 0;
return 0;
}
But when I compile using:
gcc coredump.c -g -o coredump
And run it, it still says segfault: 11
Is it still creating a core dump somewhere I don't know about? I want to be able to use gdb coredump core.
Look at this link:
How to generate a core dump in Linux when a process gets a segmentation fault?
Options include:
ulimit -c unlimited (default = 0: no core files generated)
the directory for the dump must be writable. By default this is the current directory of the process, but that may be changed by setting /proc/sys/kernel/core_pattern.
in some conditions, the kernel value in /proc/sys/fs/suid_dumpable may prevent the core to be generated.
"man core" for other options
find / -name core -print 2> /dev/null to search your filesystem for core files
I presume you're running Linux, and I presume you're executing the .exe in a directory where you have write permissions.
So my top two guesses would be 1) "ulimit -c unlimited" isn't getting set, or is being overridden, or 2) the core files are being generated, but going "somewhere else".
The above suggestions should help. Please post back what you find!
If you're running the program that crashes from the shell, then you should follow the guidelines in Apple's Tech Note TN2124, which I found out about in in the answer to SO2207233.
There are a few key points:
You need to set ulimit -c unlimited in bash (same effect, different command in tcsh).
You need to set the permissions on the /cores directory so that you can create files in it. The default permissions are 1775; you need 1777. The 1 indicates the sticky bit is set.
The core dumps are then created in /cores suffixed with a PID (/cores/core.5312, for example).
If you want programs launched graphically to dump core when they crash, then you need to create /etc/launchd.conf if it does not already exist, and add a line limit core unlimited to the file. Again, see the information in the Tech Note for more details.
Watch it; core dumps are huge! Consider this not very complicated or big program:
#include <stdio.h>
int main(void)
{
int *i = 0;
int j = 0;
printf("i = %d, j = %d, i / j = %d\n", *i, j, *i / j);
return 0;
}
The core dump from this is nearly 360 MB.
Using gcc, if you add the flags:
gcc -g -dH
you should be able to generate a core dump
The -g flag produces some debugging information to use with gdb, and the -dH flag produces a core dump when there is an error
Sometimes core files are not store in current directory and may follow a different naming rule
sysctl -a | grep kern.core
may give hints to where your core files are stored

Resources