segmentation, fault

[Anuradha]

Its giving the results now.

[jpollard]

There are lots of possible reasons -
memory failure
library differences
corrupted binary
insufficient memory
bad programming
bad install
...

Knowing what program would help. Knowing what the program does may help. Knowing which version of Fedora (I assume for the moment you are talking about Fedora 16 as there no such Fedora 16000...)

[Dan]

One thread per subject per customer at a time.

Threads merged.

[george_toolan]

Your program doesn't do anything, because you forgot to post item2.dat.

[cmanL]

Compile the program with gcc using the -g option ( for creating an executable with debugging information ) and run the resulting program using gdb ( the GNU command line debugger ). When the program crashes type "where" at the gdb prompt and the debugger will tell you where the program crashed and allow you to inspect variables in your program to help you find the segmentation fault. So do this:

gcc -g yourProgram.c

gdb a.out

GNU gdb (GDB) Fedora (7.2-52.fc14)
........
(gdb) run

segmentation fault ........

(gdb) where

myArray [ i ] = myVariable;   <- just for example here

(gdb) print i         <-print the value of the array index here , etc .......

I haven't really looked at your code but I saw arrays ( I didn't see any pointers or dynamic memory ) so I would test to see if you have an array index that is out of bounds ( too big or small compared to your declarations ) first.......

[cmanL]

On the next (gdb) prompt you should type "where" to see the location of the crash ( from the output you have you can see that the program crashes in the function "strcmp" - from the line "0x009ce118 in strcmp () from /lib/libc.so.6" ). The where command should show you the exact line of code that caused the crash , it looks like you might have passed a bad address to one of the "strcmp" function ( maybe a non-null terminated string , or you passed an address beyond the ending 0 ? ). So I would try this first. Once you find out where the crash occurred you can use other gdb commands like "print" to try to find out what the problem is. For instance:

Program received signal SIGSEGV, Segmentation fault.
0x009ce118 in strcmp () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc.i686
(gdb) where
 
if(strcmp(it.item_ids[i],item_id[j])==0) <- just for example

(gdb) print i
$1 = 839    <- array index is too big , for example

Heres an example of how to do this with a program designed to crash. Take some bad code like this:

#include <iostream>

using namespace std;
int main()
{
	int j [ 10 ];
	int i = 0;

	while ( i < 2000 )
	{
		j [ i ] = 20;
		cout << i << endl;		
		i ++;
	}
}

compile it with "g++ -g test.cpp" and run the program with gdb:

gdb a.out

gdb a.out
GNU gdb (GDB) Fedora (7.2-52.fc14)
Copyright (C) 2010 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-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/couchman/Desktop/programs/a.out...done.
(gdb) run

...... ( I cut some stuff out here )
828
829
830
831
832
833
834
835
836
837
838

Program received signal SIGSEGV, Segmentation fault.
0x080485fb in main () at test.cpp:11
11			j [ i ] = 20;
Missing separate debuginfos, use: debuginfo-install glibc-2.13-2.i686 libgcc-4.5.1-4.fc14.i686 libstdc++-4.5.1-4.fc14.i686
(gdb) where
#0  0x080485fb in main () at test.cpp:11
(gdb) print i
$1 = 839
(gdb)

Here gdb shows me that the program crashes on line 11 in the function main() ( this is the line "j [ i ] = 20;" ). I now can type the print command and this shows me that the value of "i" is much greater than the value 10 that was used to declare the array "j". So now I can rework my code so that the program does not crash. There are also several GUI debuggers that use gdb , like DDD and Eclipse IDE , so you might want to look at these too...........

[george_toolan]

If you want to use gdb you'll have to install debugging libraries for glibc et al, because the standard Fedora libraries weren't compiled with debugging symbols.

Your program crashes while parsing the input file, probably trying to read past the "end" of the file.

For testing you can just add some debugging output like this:

cout << i << ": " << it->item_ids[i] << endl;

while(strcmp(it->item_ids[i],"end")!=0)

We still don't know what your input file looks like. In your "example" it is trying to read the whole thing as one item and btw there's a difference between i5 and I5.

[Anuradha]

Thank you very much for your response. when I follow your suggestions, Iam getting the following output.

[anu@localhost ~]$ gcc -g anu.c
[anu@localhost ~]$ gdb a.out
GNU gdb Fedora (6.8-1.fc9)
Copyright (C) 2008 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 "i386-redhat-linux-gnu"...
(gdb) where
No stack.
(gdb) run
Starting program: /home/anu/a.out

Program received signal SIGSEGV, Segmentation fault.
0x009ce118 in strcmp () from /lib/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc.i686
(gdb) where
#0 0x009ce118 in strcmp () from /lib/libc.so.6
#1 0x0804880d in func1 () at anu.c:63
#2 0x08048926 in main () at anu.c:119
(gdb) print
The history is empty.

What is this no stack problem. I am having 2GB memory and 9.8GB available disk space.













[

[jpollard]

There is no stack because the process hasn't been started. The stack in question hasn't been initialized.

Your error is on line 20 - I suspect it is the line "while(strcmp(it->item_ids[i],"end")!=0)"

You have no detection for the end of file, and if the string "end" is not in the data, then you have created an index out of bounds.

[cmanL]

(gdb) print

You need to name a variable to use the "print" command. Try something like "print i".

[jpollard]

Does each item end in the string "end\0"?

If not, then you have a buffer overflow in line "while(strcmp(it->item_ids[i],"end")!=0)"

You don't check that the item has limits, just checking for "end". Not a safe way to do it.

Also note, if item is variable length (and it appears to be "maybe" then fread will read a fixed number of bytes each time - and possibly cause a synchronization problem with the data.

Can't tell without the data source or a sample...

It would also help a lot if you indented your code - makes it much more readable. Put the code in code blocks for posting...

[jpollard]

Is this by any chance a homework assignment?

There are several idiosyncrasies that make me think this - one is the recreation of a "do {}while()" construct in the generator. Another it the odd indentation...

[stevea]

Why do you use PROT_EXEC ?

I believe JPollard is correct, For reasons unclear, you are running off The end of the mmap'ed file in memory.
To debug you already have the stack trace, so change context back to func1 and print i, j, and the item data structures.
You can also print the addresses to see where in the file you are.

[george_toolan]

It is rather difficult to debug a program since you refuse to give us any information ;-)

I still don't see no item2.dat file and the program you posted is written in something like Turbo C. It doesn't compile with Linux.

So the input file was generated with dos?

If the file doesn't exist you're just getting a simple message and no segmentation fault:

open: No such file or directory

fread does have some error checking and should never try to read beyond the end of the file.

RETURN VALUE
       fread()  and  fwrite()  return the number of items successfully read or
       written (i.e., not the number of characters).  If an error  occurs,  or
       the  end-of-file is reached, the return value is a short item count (or
       zero).

While mmap just gives you a pointer. If you try to read beyond the end of the file you should get a segmentation fault, because you're poking around memory locations where you don't belong!

[hmmsjan]

if (k++ <(sb.st_size/sizeof(item))

The < operator is evaluated before incrementing k by postfix operator, thus the loop is executed one time too much.


If you change this to "if(++k<(sb.st_size/sizeof(item))", the code runs as it should run.

Because you are looking into memory out of the valid region, the results are inpredictable and Ubuntu might behave differently.

Good luck