-
August 29th, 2015, 12:38 PM
#1
Segmentation fault in C++ program
Hi,
I have a program in C/C++ that runs perfectly in my Windows 7, 32 bits.
But when I compile it in Linux, I get - only for some files reading - the "segmentation fault" error.
Below is the report of strace. Note: the overflow error of the file de431.eph does not happen with others smaller files. I don't know what might be causing this. The file is corrupted? Or is it too large?...
Code:
-bash-4.1$ strace ./swetest -p2 -j5000000 -ejplde431.eph
execve("./swetest", ["./swetest", "-p2", "-j5000000", "-ejplde431.eph"], [/* 28 vars */]) = 0
brk(0) = 0x9d90000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7705000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=31601, ...}) = 0
mmap2(NULL, 31601, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76fd000
close(3) = 0
open("/lib/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p4\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=200024, ...}) = 0
mmap2(NULL, 168064, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb76d3000
mmap2(0xb76fb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x27000) = 0xb76fb000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220n\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1902916, ...}) = 0
mmap2(NULL, 1665452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb753c000
mmap2(0xb76cd000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x190000) = 0xb76cd000
mmap2(0xb76d0000, 10668, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb76d0000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb753b000
set_thread_area({entry_number:-1 -> 12, base_addr:0xb753b6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb76cd000, 8192, PROT_READ) = 0
mprotect(0xb76fb000, 4096, PROT_READ) = 0
mprotect(0xb7725000, 4096, PROT_READ) = 0
munmap(0xb76fd000, 31601) = 0
access("/etc/sysconfig/32bit_ssse3_memcpy_via_32bit_ssse3_memmove", F_OK) = -1 ENOENT (No such file or directory)
uname({sys="Linux", node="vps.casadohosting.com", ...}) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7704000
brk(0) = 0x9d90000
brk(0x9db1000) = 0x9db1000
open("sepl_18.se1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("sepl_18.se1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("./sepl_18.se1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("de431.eph", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)
open("de431.eph", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)
open("./de431.eph", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
Might the FILE pointer be NULL for some reason?...
I would apreciate very much for some help.
Kind regards,
JKepler
-
August 30th, 2015, 04:04 PM
#2
Re: Segmentation fault in C++ program
In case your Linux system is 64-bit, you must check your code for typical 64-bit flaws. This is EOVERFLOW that makes me think that.
Best regards,
Igor
-
August 30th, 2015, 04:16 PM
#3
Re: Segmentation fault in C++ program
Originally Posted by Igor Vartanov
In case your Linux system is 64-bit, you must check your code for typical 64-bit flaws. This is EOVERFLOW that makes me think that.
Good evening Igor,
I don't have gdb installed in the server...only strace. But I've managed through its information to solve the issue. Notice the file error:
Code:
open("de431.eph", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)
I finally manage to understand the error - it wasn't in the program source code. My server is in Linux, but in a 32 bits system. So I had to compile with gcc the source but with the flag -D_FILE_OFFSET_BITS=64
The problem vanished right away...Go figure this...****... :/
Regards,
JKepler
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|